Another area programmes need to consider from the outset — even though it is rarely where they want to spend their time — is role design.
Role design often feels technical, detailed, and easy to fix later. As a result, it is frequently deferred or treated as a configuration exercise. What teams quickly discover, however, is that roles harden very early. Even roles intended to be temporary tend to persist, and programmes can become dependent on seeded (out-of-the-box) roles that are poorly aligned to overall delivery objectives.
Once this happens, unwinding role design becomes difficult, disruptive, and politically sensitive.
Establishing the ground rules early
Before roles are built, it is often beneficial to establish a small security function with a clear remit. The purpose of this function is not to dictate functional policy, but to set and uphold the ground rules for role design throughout implementation.
While such teams often have broader platform responsibilities, in the context of role design they typically focus on four questions:
- Does the role clearly reflect an identifiable business function?
- What segregation of duties–critical functions does it contain, and does it introduce any inherent conflicts?
- What is the licensing impact of the role, and does it align with programme expectations — or does it introduce unnecessary long-term cost exposure?
- Is the role genuinely required, or is it attempting to limit functionality where other mechanisms would be more appropriate, adding avoidable support and maintenance overhead?
This governance layer is often what prevents role design decisions drifting during delivery.
Designing roles through three lenses
For teams responsible for defining and building roles, the challenge is that roles must be designed through three lenses at the same time.
Lens 1: Functional capability
Roles must allow users to perform their jobs effectively. Ideally, they reflect the target job hierarchy and operating model.
This is not always straightforward, particularly in transformation programmes where a new ERP is introduced alongside organisational change. Overly restrictive roles create workarounds and operational friction; overly permissive roles create risk. In both cases, pressure on support teams increases.
Functional adequacy is necessary — but it is not sufficient on its own.
Lens 2: Compliance and control
Roles must align to the defined SoD risk model and be designed against clearly articulated critical functions. Inherent SoD conflicts need to be eliminated, and creation and approval authority must be separated and supported by appropriate workflows and delegations of authority.
It is also essential to maintain separation between configuration maintenance and transaction processing. Configuration access must be deliberately scoped, distinguishing between configuration that can reasonably be maintained by business teams and that which should remain under formal change control.
Getting this right early significantly reduces rework, audit friction, and reliance on procedural workarounds later.
Lens 3: Licensing impact (often overlooked)
Licence commitments are often made very early in programmes — frequently before detailed solution design has even begun. These commitments are sometimes based on simplified operating models and assumptions about what licences enable users to do in practice.
Role designers therefore need an implicit, if not explicit, understanding of licensing objectives and over-consumption risk. A common misconception is that “read-only” access does not consume a licence. In reality, in most modules outside HCM, licensing is driven by assigned privileges, not by whether functionality is actively used.
Casual role design, particularly through composite roles, can therefore quietly trigger licence over-consumption. In many cases, equivalent functional outcomes — especially for enquiry access — can be achieved through alternative mechanisms such as embedded reporting or deep links that do not require licence-triggering privileges.
Reducing licence consumption after the fact is technically difficult and often commercially impractical. Consumption audits surface over-use quickly, and organisations frequently find themselves locked into additional multi-year commitments before remediation is possible.
Why role design breaks down in practice
One of the most persistent challenges with role design is that roles are not always anchored clearly to real business functions.
Functional teams understandably design roles based on how they believe the business operates — organisational charts, nominal responsibilities, or future-state assumptions. In reality, day-to-day operations are more fluid. Responsibilities overlap, exceptions are common, and work rarely follows the clean lines imagined during design workshops.
As deployment approaches and users begin testing real scenarios, the inevitable feedback emerges: “I don’t have the access I need to do my job.”
At that point, roles are often adjusted quickly to keep delivery moving. Additional roles are assigned, sometimes based on trial and error rather than a clear understanding of what each role actually provides. Over time, user access profiles diverge, documentation falls behind reality, and it becomes difficult to explain why a user has a particular combination of access — other than that it works.
Once this state is reached, unwinding access becomes extremely challenging. Reviews focus on what users have rather than what they should have, and excess access becomes normalised.
Compounding this, role combinations are not always tested together during UAT or dry runs. Roles that appear safe in isolation can expose unexpected functionality when combined — behaviours that only surface under real production usage.
Finally, roles are often expected to enforce security constraints they were never explicitly designed for. Bank account access is a common example. In Oracle Fusion, users with bank account access can, by default, see all bank accounts. In multi-entity organisations, this is rarely acceptable.
Access can be restricted by named user, which is operationally brittle, or by role, which is usually the only scalable approach. The latter requires deliberate design of entity-specific security roles, careful assignment alongside functional roles, and explicit testing of combined access models. When left late, this becomes complex, sensitive, and expensive to correct.