Oracle Recruiting
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.
Learning objectives
- 1.State what Oracle Recruiting configures and where its responsibility ends
- 2.Name the seven functional areas of the Recruiting and Candidate Experience offering
- 3.Explain the person ID constraint on recruiting users
- 4.Identify the role that performs the offering opt-in
Why this matters
New implementers lose days to guessing setup paths, because the interface rewards confident clicking. Knowing that there is a documented opt-in performed by a specific role, and that the offering is divided into seven functional areas, turns "where do I start" into a lookup.
If you skip this: Configuring tasks before the offering is opted in is the single most common early stall, and it produces an error that does not name the cause.
What it is, why it exists, what breaks
What it is
Oracle Recruiting configures the complete hiring process: career sites, job application flows, candidate selection processes, job requisitions, job offers, application and interview questionnaires, recruiting campaigns, candidate pools and agency hiring.
Why it exists
It owns the candidate-facing and candidate-management side of hiring. It does not own the worker record — that begins at hire, in Core HR.
What breaks without it
Recruiting users are intended and tested for users who have a person ID assigned to their role, with agency flows the documented exception. Building a recruiting security model on users without person IDs produces access failures that look like security defects.
Source: ORC-PERSONID-003, ORC-PREREQ-002
The offering's seven functional areas
Peers of one offering, in the order a candidate meets them. Nothing on this list contains anything else on it. Listed in order: Recruiting and Candidate Experience Management, then Job Requisitions, then Candidate Experience, then Candidate Job Applications, then Job Offers, then Source Candidates, then 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.
What to take from this: Oracle Recruiting is not standalone and it does not create workers. It requires Global HR or Talent Management underneath it, the implementation consultant must opt in to the offerings first, and at the far end of the journey Core HR creates the worker record. Knowing which area owns a step tells you which configuration surface to open.
Source: ORC-OPTIN-001, ORC-PREREQ-002, ORC-OFFERING-004
Candidate journey
A candidate moves through these stages in order, and the handover to Core HR happens at the last one.
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.
What to take from this: The handoff at the end is the boundary most implementations misunderstand. Recruiting owns the candidate up to offer acceptance; Core HR creates the worker record. Anything a learner expects recruiting to do after hire — worker assignments, work relationships, payroll eligibility — belongs to Core HR.
Source: ORC-OFFERING-004, ORC-PREREQ-002
A recruiter cannot see a career site task
A recruiter is asked to create a career site. They find the task in Setup and Maintenance and cannot complete it, because the functional area appears empty.
- 1.The recruiter checks their role and confirms they have recruiting privileges.
- 2.The implementation consultant confirms the Recruiting and Candidate Experience offering was opted in.
- 3.The opt-in requires someone with the Application Implementation Consultant role, so it was not something the recruiter could do.
- 4.After the opt-in, the Candidate Experience functional area populates with its tasks, including Career Sites Configuration.
Takeaway: An empty functional area usually means the offering has not been opted in, not that the user lacks privileges.
Source: ORC-OPTIN-001, ORC-OFFERING-004
Configuration model
Objects
Recruiting and Candidate Experience offering
The unit an implementer opts in to. It contains seven functional areas and the tasks within them.
Risk if wrong: Functional areas stay empty and their tasks cannot be reached.
Functional area
The task grouping inside the offering. Seven are named for Recruiting: management, requisitions, candidate experience, candidate job applications, job offers, source candidates and the recruiting assistant.
Risk if wrong: Looking for a task in the wrong functional area is the most common time waste before setup begins.
Person ID
The identity every recruiting user needs on their role, except for agency flows.
Risk if wrong: Recruiting security behaves in ways the security design did not predict.
Constraints
- Opting in to the offering is performed by someone holding the Application Implementation Consultant role (ORA_ASM_APPLICATION_IMPLEMENTATION_CONSULTANT_JOB).
- Either Oracle Fusion Global Human Resources Cloud Service or Oracle Fusion Talent Management Cloud Service must be implemented.
- Recruiting is intended and tested for users with a person ID assigned to their role, except for agency flows.
Source: ORC-OPTIN-001, ORC-PREREQ-002, ORC-PERSONID-003
Common mistakes
Wrong: Assuming a recruiter can opt in to the offering themselves.
Symptom: The offering is not visible and no privilege appears to unlock it.
Fix: The opt-in is performed by the Application Implementation Consultant role.
Wrong: Starting with a business process task before checking the offering.
Symptom: An empty functional area and no obvious cause.
Fix: Confirm the opt-in first, then navigate by functional area.
Wrong: Creating recruiting users without person IDs, reasoning that candidates are not workers.
Symptom: Access behaves inconsistently once the security model is exercised.
Fix: Oracle states recruiting is intended and tested for users with a person ID on their role, except for agency flows. Design for that.
Wrong: Expecting Recruiting to own the worker record after hire.
Symptom: A hunt for an employee record that lives in Core HR.
Fix: The boundary is at hire. Everything after that is Core HR.
Diagnosing it
Symptom: A recruiting setup task or functional area is not visible.
Category: security
- 1.
Has the Recruiting and Candidate Experience offering been opted in to?
If no: This is the cause. The opt-in requires the Application Implementation Consultant role.
Evidence to capture: Offering opt-in record
- 2.
Is the task being looked for in the correct functional area?
If no: It exists, but not where you are looking. Career sites live under Candidate Experience.
Evidence to capture: Functional area grouping of the offering
- 3.
Does the user have the required recruiting role and data access?
If no: Privilege or data access is missing. Separate this from the offering question before escalating.
Evidence to capture: Role assignment and security profile
- 4.
Do the recruiting users hold a person ID on their role?
If no: Recruiting is intended and tested for such users, so behaviour may not match expectations. Agency flows are the documented exception.
Evidence to capture: User identity records
Confirm: Once the offering is opted in and the functional area is populated, confirm the specific task is reachable with the user's current roles.
Recall
Name the seven functional areas of the Recruiting and Candidate Experience offering, and state the person ID constraint on recruiting users.
Answer shape: Recruiting and Candidate Experience Management, Job Requisitions, Candidate Experience, Candidate Job Applications, Job Offers, Source Candidates, Recruiting Assistant. Recruiting users need a person ID assigned to their role, except for agency flows.
Memory hook: Management, Requisitions, Experience, Applications, Offers, Source, Assistant — MR E A O S A.
Source evidence
The offering structure, prerequisites, opt-in role and person ID note were read directly from Oracle's Overview of Implementing Recruiting and Recruiting and Candidate Experience Offering pages on 2026-10-05.
Release scope: FA Latest
Recorded gaps
- The pages read do not describe the Functional Setup Manager procedure for the opt-in itself, only that it is managed there.
Related concepts
- Career siteteaches
Career sites are the first thing most implementations configure after the opt-in.
- Job requisitionteaches
Requisitions are the spine of the hiring process.
- ORC to Core HR bridgecontrasts
The boundary between Recruiting and Core HR is where new implementers most often overreach.
Self-check
An auto-graded assessment is attached to this lesson: assessment-orc-mental-model
Lesson progress
Checking your progress…