# Oracle Recruiting — Module Case > Requisitions, career sites, candidate journeys, selection and offers. Exported 2026-10-05 from HCM Studio by Digi Tracks. ## Coverage 3 of 15 planned lessons are published. This is partial coverage, not a complete course. 3 recorded gaps remain, listed below. Published: **3 of 15** planned lessons. Content in this export: 3 lessons, 1 procedures, 1 scenarios, 3 assessments. Recorded gaps (see /sources/gaps for the full register): - RECRUITING-GAP-001 - RECRUITING-GAP-CSP-STATE-MAP - RECRUITING-GAP-REST-PATHS ## What this module is for Requisitions, career sites, candidate journeys, selection and offers. ## Lesson: Career sites and how they decide which jobs appear Create a career site, then understand the contextualization rule that decides which requisitions post to it — including the AND-across-OR-within logic and parent-child inheritance. Estimated time: 13 minutes · Difficulty: foundation **Objectives** - Explain what a career site does and where it is configured - State the contextualization rule and apply it to a worked example - Explain parent organization and location inheritance - Recognise that a newly created career site is inactive ### Diagram: Career site contextualization *Alt text:* A career site filtering requisitions by location and organization context, where matching any location and any organization qualifies the requisition. *Long description:* 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. ### Diagram: Career site lifecycle *Alt text:* Career site lifecycle: created Inactive, configured with context and content pages, then activated and published. *Long description:* 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. **Claims** - ORC-CAREERSITE-010 - ORC-CAREERSITE-011 - ORC-CAREERSITE-012 - ORC-CAREERSITE-013 - ORC-CAREERSITE-014 - ORC-OFFERING-004 ## Lesson: The Oracle Recruiting mental model What Oracle Recruiting is for, what it stops at, which offerings and prerequisites it has, and the one identity constraint that surprises every implementer. Estimated time: 12 minutes · Difficulty: foundation **Objectives** - State what Oracle Recruiting configures and where its responsibility ends - Name the seven functional areas of the Recruiting and Candidate Experience offering - Explain the person ID constraint on recruiting users - Identify the role that performs the offering opt-in ### Diagram: Recruiting offering functional areas *Alt text:* Seven functional areas: Recruiting and Candidate Experience Management, Job Requisitions, Candidate Experience, Candidate Job Applications, Job Offers, Source Candidates, Recruiting Assistant. *Long description:* 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. ### Diagram: Candidate journey *Alt text:* Candidate journey stages: sourced, applied, screened, interviewed, offered, hired. *Long description:* 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. **Claims** - ORC-OPTIN-001 - ORC-PREREQ-002 - ORC-PERSONID-003 - ORC-OFFERING-004 ## Lesson: Job Requisitions Over REST: Grants, Roles and What the Page Will Not Tell You Which duty role grants what on the recruitingJobRequisitions resource — and why the same role can hold both read-only and full privileges, and why this page is not where you learn the endpoint. Estimated time: 12 minutes · Difficulty: intermediate **Objectives** - Distinguish a read-only privilege from a full privilege on the recruitingJobRequisitions resource - Name the duty roles that grant each privilege level - Explain why the same role can appear under both a read-only and a full duty role - State what must be read from elsewhere before an API example is written ### Diagram: Who may act on a job requisition over REST *Alt text:* Three duty roles granting access to the recruitingJobRequisitions resource — one read-only and two full — with the roles listed under each. *Long description:* 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. **Claims** - ORC-REST-030 - ORC-REST-031 - ORC-REST-033 - ORC-REST-034 - ORC-REST-035 ## Procedures ### Create a career site and set its context so the right requisitions appear to the right external candidates, and nothing else does Create a career site and set its context so the right requisitions appear to the right external candidates, and nothing else does. **Pre-checks** - Write down the intended rule in plain language before configuring it. "UK roles only" and "UK roles in UK Operations" are different contexts and produce different sites. - Confirm the organizational hierarchy, because a parent context publishes its children. - Confirm whether the site is intended to be public to all external candidates. A wrong context on a public site is a disclosure risk, not just a usability one. **Steps** 1. **Open Career Sites Configuration** — In the Setup and Maintenance work area, go to Offering: Recruiting and Candidate Experience, Functional Area: Candidate Experience, Task: Career Sites Configuration. 2. **Start a new site** — Click the Add Site icon, then enter a name and a code for the career site. Remember the name is the public title that appears in the browser. 3. **Set the languages** — Select a default language for the career site. If the site should be available in several languages, click Manage Languages and select the others. 4. **Choose a template or reuse content pages** — Select a template. If custom content pages were created for another career site, select the ones to use; otherwise the template splash page is used. 5. **Set the context** — Contextualize the career site using job requisition locations, organizations, job categories, job functions, recruiting types and job requisition flexfields. Within each context the OR operation applies; across all contexts you set, the AND operation applies. If an organization or location is the context, requisitions for that parent and for its child organizations or locations are posted. 6. **Create the site** — Click Create Site. The site is created with the status Inactive. Activation is a separate configuration step that is not described on the page this procedure is based on, so consult your own product documentation for it. **Verify** - Test the context against requisitions that should appear and requisitions that should not. Both directions matter. - Confirm a child organization or location requisition appears when its parent is the context, because that is documented inheritance rather than a bug. - Before activation, confirm no requisition appears that the organisation has not approved for external publication. **If it fails** | Symptom | Cause | Resolution | | --- | --- | --- | | A site scoped to one country and one business unit shows requisitions from other countries. | The AND-across-contexts rule was applied as OR. | Narrow the context so every context set must match. Re-test against a requisition that matches only some contexts, which should be excluded. | | A requisition for a child business unit appears on a site scoped to its parent. | Parent context publishes child requisitions by documented design. | Either accept the inheritance as intended, or set the context on the child organization instead of the parent. | | The site exists and is configured but appears nowhere externally. | A newly created career site has the status Inactive. | Complete the activation step in your own product documentation, then re-test the context externally. | | The site shows a generic template page instead of the content you designed. | No custom content pages were selected, so the template splash page was used. | Select the custom content pages created for another site, or accept the splash page as the intended outcome. | ## Scenarios ### A UK-only career site is showing a US job A career site was created with a United Kingdom location context and a UK Operations organization context. A recruiter expects it to show only UK roles. A US Operations requisition has appeared in its search results. **Objective:** Explain why the US requisition appears, and correct the configuration without publishing the wrong roles. **Stakes:** A live career site with the wrong context either publishes roles the organisation did not intend to disclose, or hides roles it needed filled. ## Assessments ### Self-check: job requisitions over REST Four questions on the read-only and full privilege sets, the duty roles that grant them, why a role can appear twice, and what the security page does not tell you. 4 questions · pass mark 70% ### Self-check: career sites and contextualization Four questions on the OR-within / AND-across rule, parent-child inheritance, and the two documented fallbacks. 4 questions · pass mark 70% ### Self-check: the Oracle Recruiting mental model Four questions on the implementation prerequisite, the seven offering functional areas in candidate order, and the person ID constraint. 4 questions · pass mark 70% ## Related Oracle certifications HCM Studio does not issue Oracle certifications. These are the Oracle credentials this module’s content is relevant to; confirm current details with Oracle. - **Oracle Fusion Cloud Applications HCM Process Essentials** (1Z0-1162-1, Foundations) — 27 authored lessons in this module and its siblings. https://mylearn.oracle.com/ou/exam-unproctored/oracle-fusion-cloud-applications-hcm-foundations-associate-rel-1-1z0-1162-1/146869/240498 - **Oracle Recruiting Cloud 2026 Implementation Professional** (1Z0-1069-26, Professional) — 3 authored lessons in this module and its siblings. https://mylearn.oracle.com/ou/exam/oracle-recruiting-cloud-2026-implementation-professional-1z0-1069-26/107076/158919/264905 - **Oracle Talent Management Cloud 2026 Implementation Professional** (1Z0-1052-26, Professional) — 3 authored lessons in this module and its siblings. https://mylearn.oracle.com/ou/exam/oracle-talent-management-cloud-2026-implementation-professional-1z0-1052-26/107076/158905/264897 --- Produced by HCM Studio. Oracle Fusion Cloud HCM documentation is Oracle's copyright and is linked, never reproduced. 33 diagrams are included as text descriptions so this document prints without images.