Core HR
The Security Model: What You Can Do, What You Can See, and Where It Is Configured
Role-based access has two halves — job, abstract and duty roles decide what a user can do, data roles with security profiles decide what they can see — and where the settings live depends on whether the implementation is finished.
Learning objectives
- 1.Distinguish the functional half of security from the data half
- 2.State where security tasks are performed during implementation and afterwards
- 3.Explain what regenerating data security policies is for and when it is required
- 4.Explain what location-based access decides
Why this matters
"Why can this user see that worker?" sounds like one question and is always two. Whether a user can perform an action is decided by their job, abstract and duty roles. Which rows the action reaches is decided by data roles and the security profiles attached to them. A user with the right function role and the wrong data role can open the page and see nothing; a user with the wrong function role cannot open the page at all — and both present as "I do not have access", which is why the first diagnostic step is deciding which half you are in.
If you skip this: Grants are added to the wrong half for long enough that the model becomes unreadable, and the cleanup is a role-hierarchy project rather than a configuration fix.
What it is, why it exists, what breaks
What it is
Oracle HCM Cloud security is role-based. Job, abstract and duty roles are created and edited on the Security Console — by copying a predefined role, creating a role from scratch, or editing a custom role — and HCM data roles and HCM security profiles identify the data users can access.
Why it exists
Two halves, one console. The functional roles and the data roles are maintained in the same place, which is what makes the model reviewable: the role hierarchies and the role analytics are there too.
What breaks without it
When the role hierarchy changes, the data security policies of data and abstract roles must be regenerated — so a hierarchy edit that is saved but not followed by a regeneration is only half applied, and the half that is missing is the data half.
Source: SEC-HCM-001, SEC-HCM-004, SEC-HCM-005, SEC-HCM-006
The two halves of the security model
Two columns, not a chain: functional roles and data roles are separate halves of one role-based model, and a grant to one does not reach the other. Listed in order: Job, abstract and duty roles, then HCM data roles and security profiles, then The phase rule, then Role hierarchy regeneration, then Location-based access.
Oracle HCM Cloud security is role-based, and it has two halves. The functional half is job, abstract and duty roles, which decide what a user can do. The data half is HCM data roles and HCM security profiles, which decide what data a user can see: person security profiles secure access to person records, and organization and other security profiles secure access to organizations, positions, document types, legislative data groups, payrolls and payroll flows. The diagnostic value of the split is that the two failures present differently — a user whose function roles are wrong cannot open the page at all, while a user whose data roles are wrong opens it and finds it empty, and both say "I do not have access". Beneath both halves sits the phase rule for where the settings live: during implementation, security-related tasks are performed from a functional area task list or implementation project; after implementation, most are performed on the Security Console, and the exceptions are named where they apply — workers are hired in the New Person work area, never on the console. Two further rules complete the model. When the role hierarchy changes, the data security policies of data and abstract roles must be regenerated, so a saved hierarchy change is only half applied until it is. And location-based access is enabled by listing authorized IP addresses, with selected roles that can be made public, so a refusal from one network while every role is granted is a location problem rather than a role problem.
What to take from this: The picture has two columns and a location. On the left, the functional roles deciding what a user can do; on the right, the data roles and security profiles deciding what data they can see; and beneath both, the phase rule that says where the settings are found — task list during implementation, Security Console afterwards, with named exceptions like hiring a worker, which happens in the New Person work area and never on the console.
Source: SEC-HCM-003, SEC-HCM-004, SEC-HCM-005
The consultant who could open the page and see nothing
A functional consultant is added to an in-flight implementation to help with absence setup. They are granted a duty role that includes the absence setup task, they navigate to the work area, the page opens — and every list is empty. A peer with the same duty role sees rows.
- 1.The function half is working: the duty role reached the task, and the page rendered.
- 2.The data half decides what the page contains, and it is governed by data roles with security profiles.
- 3.The comparison that matters is not role against role but data role against data role — which security profiles each carries.
- 4.The missing grant is a data role, which is not the same kind of object as the duty role that was granted.
Takeaway: "I can open it but it is empty" is the data half. "I cannot open it at all" is the functional half. Naming which half you are in is the fastest diagnostic step in the security model, and it is a step, not a conclusion.
Source: SEC-HCM-001, SEC-HCM-005
Configuration model
Objects
Job, abstract and duty roles
The functional half: what a user can do. Created and edited on the Security Console by copying a predefined role, creating from scratch, or editing a custom role.
Risk if wrong: A missing duty role presents as "the task is not on my list", which is easily mistaken for a navigation problem.
HCM data roles and security profiles
The data half: what a user can see. Person security profiles secure access to person records; organization and other security profiles secure access to organizations, positions, document types, legislative data groups, payrolls and payroll flows.
Risk if wrong: A missing or wrongly scoped data role presents as empty lists on pages the user can open, and as "I can see some workers but not others" when the profile scope is narrower than the expectation.
Role hierarchy regeneration
Rebuilds the data security policies of data and abstract roles when the role hierarchy changes.
Risk if wrong: A saved hierarchy change without a regeneration is half applied, and the half missing is the data half — the one that decides visibility.
Location-based access
Restricts where access is allowed from, by listing authorized IP addresses, and selected roles can be made public.
Risk if wrong: Access that fails from an unlisted network reads as a permissions problem, because the user has the roles and still cannot get in.
Constraints
- Oracle HCM Cloud security is role-based.
- During implementation, security-related tasks are performed from a functional area task list or implementation project.
- After implementation, most security-related tasks are performed on the Security Console, and exceptions are identified in the relevant topics — you hire workers in the New Person work area, not on the Security Console.
- On the Security Console you set enterprise options, review role hierarchies and role analytics, and create or edit job, abstract and duty roles.
- HCM data roles and HCM security profiles identify the data users can access.
- When the role hierarchy changes, the data security policies of data and abstract roles must be regenerated.
- Location-based access is enabled by listing authorized IP addresses, and selected roles can be made public.
Source: SEC-HCM-001, SEC-HCM-003, SEC-HCM-004, SEC-HCM-005, SEC-HCM-006, SEC-HCM-007
Common mistakes
Wrong: Searching the Security Console for a task that belongs to a functional area work area.
Symptom: The setting is "missing" from the console, and the conclusion is that the environment differs from the documentation.
Fix: During implementation, security-related tasks sit in a functional area task list or implementation project. After implementation most move to the Security Console, and the exceptions are named where they apply — hiring happens in the New Person work area, never on the console.
Wrong: Treating "I can open the page but it is empty" as a permissions refusal.
Symptom: More function roles are granted, nothing changes, and the user now has more access than they need to the wrong half.
Fix: An empty page is the data half: data roles and security profiles decide what the page contains. Compare security profiles, not duty roles.
Wrong: Editing the role hierarchy and not regenerating the data security policies.
Symptom: The change appears in the hierarchy and makes no difference to what users can see.
Fix: The data security policies of data and abstract roles must be regenerated when the role hierarchy changes. A hierarchy edit without a regeneration is half applied.
Wrong: Reading a location-based access failure as a role problem.
Symptom: A user with every required role cannot sign in or reach the application from one network and can from another.
Fix: Location-based access is decided by the list of authorized IP addresses, not by roles. Check the network before re-granting.
Diagnosing it
Symptom: A user can reach a work area but sees no data, or cannot reach a task a colleague with a similar role can reach.
Category: security
- 1.
Can the user open the page at all?
If no: The functional half is the problem: a job, abstract or duty role is missing. Compare duty roles, not security profiles.
Evidence to capture: The duty roles granted to this user against one granted to a user who can open it
- 2.
Does the user hold a data role carrying security profiles that cover the rows in question?
If no: The data half is the problem: the page opens and the profiles do not reach the data. Compare security profiles between the two users.
Evidence to capture: The HCM data roles and the person or organization security profiles each user carries
- 3.
Has the role hierarchy changed since the data security policies were last regenerated?
If no: A saved hierarchy change without a regeneration leaves the data half half-applied. Regenerate, then retest.
Evidence to capture: The date of the last role regeneration against the date of the last hierarchy change
- 4.
Is the user on a network the location-based access list authorizes?
If no: The roles are correct and the network is the refusal. Location-based access lists authorized IP addresses.
Evidence to capture: The IP address the user connects from against the authorized list
Confirm: Confirm which half the symptom is in — function roles for "cannot open", data roles and security profiles for "opens but empty" — and that the hierarchy regeneration is current before changing any grant.
Recall
Name the two halves of the security model and say what each decides, where security tasks are performed during implementation versus afterwards, and what must be regenerated when the role hierarchy changes.
Answer shape: The functional half is job, abstract and duty roles, deciding what a user can do. The data half is HCM data roles with security profiles, deciding what data they can see — person security profiles secure person records, organization and other security profiles secure organizations, positions, document types, legislative data groups, payrolls and payroll flows. During implementation the tasks sit in a functional area task list or implementation project; afterwards most sit on the Security Console, with named exceptions such as hiring in the New Person work area. When the role hierarchy changes, the data security policies of data and abstract roles must be regenerated.
Memory hook: Can do versus can see. Task list before, console after. Regenerate when the hierarchy moves.
Source evidence
The role-based scope, the two halves, the Security Console capabilities, the security profile types, the phase rule, the regeneration requirement and location-based access were read from the Overview of Securing Oracle HCM Cloud page on 2026-10-09.
Release scope: FA Latest
Recorded gaps
- The page read is an overview that maps the chapters of the security guide. It names what exists and where tasks are performed; it does not describe how to perform them. This lesson stays at that altitude and teaches no procedures — for example, how to create a data role, how to scope a person security profile, and how the public-role option of location-based access behaves are not asserted here.
- The page names abstract-role basic data access for employees, contingent workers and line managers as a chapter of the guide. What "basic data access" comprises for those roles is not stated on the page read, so this lesson does not claim it.
- The optional advanced services — Database Vault and Transparent Data Encryption — and the Role Optimization Report are named on the page and not described, so none of the three is taught here.
Related concepts
- The enterprisedepends on
Enterprise options for security are set on the Security Console, and the enterprise is the boundary the rest of the model is defined within.
- Work relationshipreferenced by
The phase rule names hiring as the exception: workers are hired in the New Person work area, and the work relationship that hire creates never touches the Security Console.
Self-check
An auto-graded assessment is attached to this lesson: assessment-core-hr-security-model
Lesson progress
Checking your progress…