Oracle Recruiting — Module Case

Alt text: A career site filtering requisitions by location and organization context, where matching any location and any organization qualifies the requisition.

A career site publishes the requisitions that match the context configured on it. Within a single context, for example location, the operation is OR: a requisition matching any one of the configured locations qualifies. Between the contexts that are set, for example location and organization, the operation is AND: the requisition must satisfy every configured context. So a site with one UK location and one UK Operations organization context publishes only UK requisitions in that organization. There is a second rule that catches people out: a parent context also publishes its children, so a site scoped to UK Operations will publish requisitions belonging to a child organization unless the organization context is narrowed.

Alt text: Career site lifecycle: created Inactive, configured with context and content pages, then activated and published.

A career site is created with the status Inactive, which means nothing is public from it yet. It is then configured: contextualization dimensions are chosen to select which requisitions qualify, and content pages are selected to control what the site looks like. If no custom content pages are selected, the template splash page is used as the fallback, so an unconfigured site looks generic rather than broken. The site is then activated, which is what makes the matching requisitions public. Activation is the point where a contextualization mistake becomes a public mistake, which is why the context should be tested against sample requisitions before activation rather than after.

Alt text: Seven functional areas: Recruiting and Candidate Experience Management, Job Requisitions, Candidate Experience, Candidate Job Applications, Job Offers, Source Candidates, Recruiting Assistant.

The Recruiting and Candidate Experience offering contains seven functional areas. Recruiting and Candidate Experience Management is the administration layer. Job Requisitions covers creating and managing the openings. Candidate Experience is what a candidate meets first, because a career site is the entry point into it. Candidate Job Applications covers the application itself. Job Offers covers the offer and acceptance. Source Candidates covers agency and sourcing. Recruiting Assistant is the guided setup surface. A candidate journey moves through them roughly in that order: they arrive at Candidate Experience, apply, progress through selection, and reach Job Offers. Knowing which area owns a step is how you know which configuration surface to open.

Alt text: Candidate journey stages: sourced, applied, screened, interviewed, offered, hired.

A candidate moves through these stages. Sourced: they enter the pipeline, from a sourcing channel or a talent community. Applied: they submitted an application through a career site or a job application. Screened: qualifications are checked against the requisition requirements. Interviewed: the interview stage, whose outcomes depend on the requisition and the recruiting configuration. Offered: an offer is created, and acceptance moves them forward. Hired: they are accepted, and at that point Oracle Recruiting hands off to Core HR, which creates the worker record. That handoff is the boundary most implementations misunderstand: the person is not a worker until Core HR has created them, and Oracle Recruiting requires the implementation consultant role to opt in to the applicable offerings first.

Alt text: Three duty roles granting access to the recruitingJobRequisitions resource — one read-only and two full — with the roles listed under each.

Access to the recruitingJobRequisitions REST resource is granted through Duty Role grants, so the unit of access is the duty role rather than the user or even the job role. Three duty roles appear. Use REST Service - Job Requisitions Read Only, abstract role name ORA_IRC_REST_SERVICE_ACCESS_JOB_REQUISITIONS_RO, grants Get and Describe and nothing that changes a requisition. Two further duty roles grant the full privilege set of Get, Post, Patch, Describe and Delete: Access Recruiting Activity Center, ORA_IRC_ACCESS_RECRUITING_ACTIVITY_CENTER_DUTY, and Use REST Service - Job Requisitions, ORA_IRC_REST_SERVICE_ACCESS_JOB_REQUISITIONS. The case worth stopping on is that the Human Capital Management Integration Specialist role is listed under both the read-only duty role and a full-privilege duty role. The same role therefore has write access in one deployment and not in another, with the role configuration looking identical in both, and the difference is which duty role was granted. Hiring Manager and Recruiter are listed under the Access Recruiting Activity Center duty role only, and under neither REST service duty role. One boundary is deliberate: this page is a privilege matrix and contains no endpoint URI, request schema, response schema or field names. Those must be read from the corresponding resource page in the REST API guide, and an integration written from the matrix alone gets every grant right and every payload wrong.