The access that survived a transfer

A finance analyst moved into an HR business partner role in March. Eight months later an internal audit found she could still open compensation records for her old cost centre. Her role list looked correct, and every entry on it had been approved by the security team.

The cause was an assignment nobody had ended and a provisioning rule that granted a role when that assignment was created. The rule fired once, the grant stayed, and the scope attached to it kept pointing at a population she had left. Reading her roles told the auditors nothing, because the roles were fine. The records those roles reached were the problem.

Most Oracle Fusion HCM security problems live in that gap between what a person can do and whose records they can do it to. Function access gets the attention in design workshops because it is visible on a page. Data scope decides whether a mistake is an inconvenience or something you have to report.

Function access and data access answer different questions

Four parts are worth holding in your head at once. A job role describes what someone is employed to do. Duty roles sit under it and carry the actions that job needs, which carry the privileges that let a page open or a field save. Abstract roles cover what a person is rather than what they do, such as being an employee or a line manager.

Scoping is a separate mechanism. Security profiles decide which people, positions, organizations and payrolls that function access applies to, and a data role binds a job role to a particular scope. Whether your Oracle HCM implementation uses data roles, direct security profile assignment, or both varies by module and by release, so confirm which one is live in your own environment.

Two people can hold identical function access and legitimately see completely different populations. That is the model doing its job. The failure runs the other way. A correct job role attached to the wrong security profile gives somebody the right actions on the wrong people, and that is what puts salary detail in front of someone who should never see it.

Copy the delivered role and leave the original alone

Copying a delivered role and editing the copy is the right instinct. Editing a delivered role directly is not, because those definitions belong to Oracle and get refreshed. An upgrade can reinstate a privilege you removed or add one you never reviewed, and you find out when somebody opens a page they could not open last week. A copy survives the upgrade.

The cost of the copy arrives later. Delivered roles change between releases and your copy does not inherit those changes. Someone has to read the release material each cycle and decide whether a new duty or privilege belongs in your version. Skip that review and your copies fall behind, which surfaces when one user cannot finish a task everyone else completes.

Inheritance is the part people approve without reading. A job role pulls in duty roles, those pull in further duty roles, and the effective access of a person runs far wider than the entries on their role list. Nobody should approve a role without seeing the full inherited tree and the privileges at the bottom of it.

Fewer roles with well-designed data scoping beats many near-duplicates, and the reason is maintenance. Twelve scoped roles can be reviewed in an afternoon. Two hundred near-duplicates cannot, and they drift until nobody can say what separates two of them, the same trap teams fall into with Workday security groups. The counterweight is honest. Consolidation pushes people toward broader function access, and a role scoped tightly today stays broad when somebody loosens the scope next year.

An inaccurate reporting line is a data exposure

Person security profiles built on the line manager hierarchy are the most common source of access nobody intended. When a worker sits under the wrong manager, or a manager change was entered with the wrong effective date, that manager sees a population they have no business seeing, and the people affected have no way to notice.

HR teams file a wrong reporting line under tidy-up work for later. In Fusion it is an access change. Any correction to a supervisor, a position hierarchy or an organization tree moves data visibility, backwards or forwards depending on the effective dates involved. Agree those dates with the security team before the correction is entered.

Role provisioning rules are the mechanism behind access that appears after a transfer and never leaves. A rule evaluates assignment attributes and grants roles when they match. Depending on how the rule and the role mapping were configured, the grant may not be withdrawn when the attributes stop matching, and roles added by hand are not withdrawn at all. Behaviour differs by release and by setup, so rehearse a transfer in a test environment and watch the old roles. It is the identity lifecycle problem with payroll data attached.

Payroll and compensation are a different kind of mistake

Over-granting in absence or goal management produces awkwardness. Over-granting in payroll or compensation produces a disclosure you cannot withdraw, and in several jurisdictions one you must report. Give payroll and compensation a separate approval path, a named owner, and a shorter review cycle than the rest of HCM.

Payroll security carries its own scoping objects on top of person scoping, so a user can hold payroll function access and still be limited to particular payrolls or flows. Compensation visibility can depend on plan and hierarchy configuration rather than on the person profile alone. Which objects apply depends on the modules you licensed, so map them yourself. The same review should catch the combinations one person ends up holding across modules.

Proxy and delegation belong in that review. When one user works on behalf of another, the access in play is the target's, and the audit trail has to show who was at the keyboard. Keep delegations time-bound, re-read the standing ones each cycle, and check what a delegate could reach during a payroll run rather than on a quiet Tuesday.

The same report shows different numbers to different people

Analyses and transactional reports honour the data access of whoever runs them. Two managers open the same report and see different totals, and both totals are correct. That is a security control and a reporting correctness problem at the same time, because a headcount somebody quotes in a meeting is only the headcount they were allowed to see.

You cannot test a report by running it yourself. An administrator with wide access sees everything and decides the report works. The manager it was built for sees a subset and decides the numbers are broken. Run every report with the access of a real person from its intended population, and record who that was beside the report definition.

Where a report has to show a complete picture regardless of who opens it, make that a deliberate design decision, usually by moving the figure out of the transactional layer into something with its own access rules. Decide it early, because the reporting architecture question is much harder to revisit once finance has built a quarterly pack on it.

Prove it by becoming the person

Reading configuration cannot tell you what someone can see. A role list, a security profile and an inherited privilege tree describe an intention. The result depends on the person's assignment, the hierarchy on the day, the effective dates on every one of those records, and how each module resolves them.

So verify by becoming the person. Sign in as a real worker in a real position, or proxy to them where your governance allows it, and look at what comes back. Pick the awkward ones. Somebody with two active assignments. A manager covering a vacant position. A worker who changed legal entity last quarter. A contingent worker. Those are the cases where the model bends.

Start with the most recent internal move in your organization, sign in as that person, and try to open a compensation record for somebody on the team they left. Then run the same pass every time you change a role, a security profile or a provisioning rule.

  • Sign in as a real person holding the role, in the position they hold today.
  • Search for workers and confirm the population returned is the one you intended.
  • Confirm a named out-of-scope worker is absent from that result.
  • Open salary and payroll detail for an in-scope worker, then try the same out of scope.
  • Run the reports that person uses and check the totals against the population you expected.
  • Expand the full inherited role tree and read the privileges nobody mentioned in design.
  • Move the test worker to a new manager, repeat every check, and confirm old visibility is gone.
  • Record who you tested as, the date, and what you saw, so the next reviewer can repeat it.