Fusionadvanced

Fusion Security Model: Roles and Data Security

Explain Oracle Fusion's role-based access control model and how it differs from EBS's responsibility model

Fusion Cloud replaces EBS's Responsibility model with a much more granular Role-Based Access Control (RBAC) hierarchy built on four layered role types: Duty Roles (the smallest grain, representing a specific task like 'Invoice Entry Duty'), Job Roles (a collection of duty roles representing a real job, like 'Accounts Payable Specialist'), Abstract Roles (represent a person's status rather than job, like 'Employee' or 'Line Manager'), and Data Roles (a job role scoped to specific data, like a specific Business Unit).

Fusion's security model is like a hospital's staff badge system: a badge (job role) is built from specific certified skills (duty roles) like 'can administer medication', and separately, the hospital's records system restricts which patients' charts (data security) that badge can open based on which ward the staff member is assigned to — function access and data access are governed independently but combined at the point of use.

Key Concepts

1
This layered design separates function security (what actions/pages a role can access) from data security (which specific data instances — which Business Unit, which Ledger, which Department — the role can see), implemented through Data Security Policies that combine a role, a database resource, and a condition (often referencing HCM Security Profiles or similar constructs) to determine row-level visibility.
function securitydata securityData Security Policies
2
Roles are provisioned to users either directly or, more commonly at scale, through role mappings tied to HR attributes (like job, department, or grade), meaning a new hire automatically inherits the correct access when their HR record is created, without manual role assignment — a stark contrast to EBS's manual per-user responsibility assignment.
role mappings
3
Interviewers commonly probe whether a candidate understands the distinction between function security and data security, and can explain how a custom role would be built by combining existing duty roles rather than starting from scratch, since Oracle strongly discourages modifying seeded roles directly (instead, copy and extend).