🏗️ OasisPro · Role Design · PermissionWorks
Designed in a rush
at go-live.
Still causing findings.
IFS Cloud role design decisions made once, under deadline pressure, during implementation, have a way of compounding for years. A Role built "broad, just to be safe" to hit a go-live date becomes next year's access review finding, the year after's segregation of duties conflict, and eventually a line item in a permission project's cost, and by then nobody remembers why it was designed that way.
The person who made the original call has often moved on. The documentation, if it ever existed, rarely survives. What's left is the Role itself, still granting whatever it was given at the time, quietly aging into risk.
Here are the 6 mistakes worth fixing now, before they compound any further.
A Role that's too broad doesn't announce itself. It just sits there, working fine, until an access review or an SoD check finally goes looking for exactly this kind of problem.
Every one of these mistakes traces back to a decision that felt reasonable in the moment: a deadline, a job title used as a shortcut, a permission added "just in case." None of them look like mistakes until someone checks, months or years later.
The 6 IFS Cloud role design mistakes that compound
- 1. Designing around job titles instead of actual tasks. A title is a convenient shortcut, not a specification. Designing directly from it almost always produces broader access than the role genuinely requires.
- 2. "Just in case" permissions added under go-live deadline pressure. Added to avoid a support ticket during cutover week, never revisited once things stabilized, and still sitting there today.
- 3. One Role reused across genuinely different job functions. "Close enough" at the time becomes a Role that's simultaneously too broad for some holders and mildly wrong for all of them.
- 4. No naming or documentation convention. Nobody today knows what a Role was actually designed to allow, only what it happens to allow, which makes narrowing it later a research project instead of a quick fix.
- 5. Roles never re-validated after an IFS Cloud upgrade. An upgrade can change what a Role actually grants underneath, at the Projection and Action level, without anyone re-checking that the original intent still holds.
- 6. No named owner assigned to the Role. Without a specific, accountable person, nobody is actually responsible for reviewing or narrowing it as the organization's real needs change over time.
Why title-based design always runs broad
A job title covers a range of possible tasks. Designing to the widest interpretation of that title, just to be safe, is how a Role ends up granting more than any actual holder needs.
Why go-live leftovers never get cleaned up
Nobody schedules a follow-up to remove the emergency permissions added during cutover week. Once the crisis passes, so does the attention, and the permission just stays.
Why ownership is the fix that fixes everything else
A named owner is the one thing that turns every other mistake on this list from permanent into fixable, because someone is now actually accountable for noticing and correcting it.
The fastest way to find your own existing mistakes
Cross-reference current Roles against actual usage. A Permission Set granting access nobody assigned to that Role has used in the last twelve months is a strong, concrete signal that the original design was broader than the role ever actually needed.
How to design Roles that don't compound into problems
Start from the actual Projection and Action combinations a task requires, not from a job title's broadest reasonable interpretation.
Document the intent behind every Role at the time it's created, not as an afterthought once someone asks why it exists.
Assign a named owner to every Role, and revisit that Role specifically after any IFS Cloud upgrade that could change what it actually grants underneath.
A Role built "just to be safe" at go-live isn't safe. It's just risk with a delay built into it.
What fixing this now actually prevents
Next year's access review finding, already visible today to anyone who cross-references Roles against actual usage.
A segregation of duties conflict hiding inside a Role that was reused across two functions it was never really designed for.
A permission project years from now that costs more specifically because nobody documented the original intent behind the Roles it has to untangle.
We'll find the go-live shortcuts still sitting in your Roles.
PermissionWorks cross-references current Roles against actual usage and the Projections and Actions they genuinely grant, surfacing exactly which design decisions are quietly broader than they need to be.
See the conflicts this often traces back toFix the role design decision before it becomes next year's finding.
Send us your current Roles and Permission Sets, and we'll flag which ones are broader than actual usage justifies, and which ones have no named owner at all.
Why do role design mistakes take so long to surface?
Because a Role that is slightly too broad does not break anything visibly. It sits there quietly until an access review or an SoD check specifically looks for it, which is often the first time anyone examines the original design decision at all.
Should Roles be designed around job titles or around tasks?
Around tasks, specifically the Projection and Action combinations someone actually needs to do their job. Job titles are a convenient label, but designing directly from a title tends to produce broader access than the role genuinely requires.
What is the fastest way to find existing role design mistakes?
Cross-reference current Roles against actual usage. A Permission Set granting access nobody in that Role has used in the last year is a strong signal the original design was broader than necessary.
Who should own a Role once it is designed?
A named individual, typically a process or department owner, not IT as an abstract catchall. Without a named owner, nobody is accountable for narrowing a Role as the organization's actual needs change over time.
Fix the decision, not just the finding
An access review finding or an SoD conflict is usually just the visible symptom of a role design decision made once, in a hurry, years ago. Fixing the finding without fixing the underlying design just means the same mistake resurfaces later.
Six mistakes. All of them fixable now, before the next review finds them for you.