🧭 OasisPro · IFS Cloud Role Design · Access Architecture · PermissionWorks
Design the roles first.
Everything else follows from it.
IFS Cloud role design is the part of a security workstream that most projects skip, and skipping it is why so many organisations end up with one bespoke permission set per employee and nobody willing to touch any of them. Ask any IFS partner on your shortlist how long permission design should take on a system your size. The answers will vary enormously, and how they answer tells you more than the number itself.
A consultant with real depth will ask about your role model before quoting anything. Someone without it gives you a figure, because a figure sounds confident.
These are the 7 rules to insist on, whoever you appoint.
Permission sets are the output. The role model is the deliverable. Get that the wrong way round and you build something technically correct that nobody can maintain.
A role model is written in business language: what a planner does, what a buyer approves, what a warehouse supervisor releases. It is agreed with the people who do those jobs. Only once it exists does configuration begin, and at that point most of the hard decisions have already been made in a room rather than in a screen.
The 7 rules of IFS Cloud role design
- 1. Model job functions before touching configuration. Write down what each role does, in the words the business uses. This document is the thing you are actually building.
- 2. Start from the standard sets IFS ships. Adapting a maintained baseline is faster than composing from nothing and survives future releases considerably better.
- 3. Compose from small reusable blocks. Functional building blocks combined into role-level access scale. Monolithic sets do not, and neither does one set per individual.
- 4. Start with fewer roles than you think you need. Roles multiply on their own over time. Beginning with sixty variations guarantees a model nobody can reason about by year two.
- 5. Test with real users doing real daily work. Not a review of the permission list. Blocked work is the only honest signal that the design is wrong.
- 6. Document the intent, not just the contents. Record what each role is meant to permit and why. The next person to change it needs the reasoning, not the configuration.
- 7. Give it an owner for after go-live. Roles change constantly through leavers, joiners and restructures. Without ownership the model drifts within months.
What a good answer sounds like when you ask a partner
They ask how many distinct job functions you have and whether they are documented. They ask who has authority to decide what a planner needs. They talk about adapting standard sets rather than building from scratch. They insist on real-user testing. And they tell you plainly that they cannot size the work until the role model exists. That last one is the strongest signal of the lot.
Where IFS Cloud role design usually goes wrong
It gets started too late, after functional configuration, when access requirements were determined by process decisions taken weeks earlier.
It gets delegated entirely to IT or to the implementation partner, neither of whom can decide what a buyer should genuinely be allowed to approve.
It gets built by copying an existing user, which feels efficient and produces a model with no structure at all.
And it gets signed off on paper rather than proved in use, which defers every problem to the week after go-live.
The IFS documentation site covers the underlying concepts, and the IFS Community is where practitioners compare real approaches.
Our 7 checks before choosing an IFS consultant covers how to test the rest of a partner's depth.
Anyone who can size your permission work before seeing your role model is guessing, confidently.
A worked example of IFS Cloud role design
Take a warehouse supervisor. In business language they receive goods, confirm quantities, resolve discrepancies, release work orders and view stock across their site.
That description is the role model entry. It is agreed with an actual supervisor, not inferred from what the last person's account happened to allow.
From it you compose access out of functional blocks: goods receipt, stock enquiry, work order release. Each block is reusable by other roles that need the same capability.
When the process changes next year, you adjust one block rather than auditing forty individual permission sets to find every place the capability was granted.
That is the entire argument for composable IFS Cloud role design, and it only becomes visible about eighteen months after go-live.
Keeping IFS Cloud role design healthy after go-live
Review the model annually and after any significant restructure, with someone accountable for confirming that assigned access still matches current job functions.
Handle leavers and movers continuously rather than at review time, because the gap between a job change and an access change is where problems accumulate.
Give temporary elevated access an owner and an expiry date. Exceptions are legitimate; exceptions nobody revisits are how models drift.
And resist adding a new role every time somebody asks. Most requests are satisfied by an existing role plus one block.
How IFS Cloud role design interacts with everything else
Access is not an isolated workstream. Reporting depends on it, because a report a user cannot open is indistinguishable from a report that does not work.
Data migration depends on it, because loaded records mean nothing if the people who need them cannot see them.
Integrations depend on it, because service accounts need deliberate access rather than whatever was convenient during testing.
Good IFS Cloud role design therefore has to run alongside those workstreams rather than after them, which is a sequencing decision taken at planning time.
Good IFS Cloud role design plus automation is the fast combination.
Once the role model exists, generating and validating the permission sets behind it is pattern work at volume. PermissionWorks handles that part, removing roughly 80 percent of the manual effort, while your team keeps every approval decision. No IFS Solution Manager access needed after integration.
The 6 fixes for permission overrunBring us three of your real job functions.
We will show you what a documented role model looks like for them, what generated permission sets produce against it, and how the review and approval process runs. It is the fastest way to see whether your current approach is going to scale.
What is a role model in IFS Cloud?
A role model is the documented set of job functions in your business and what each genuinely needs to do. It sits above permission sets and is written in business language rather than technical terms. Without it, access gets configured per individual, which produces a system nobody can reason about within a year.
How many roles should an IFS Cloud implementation have?
Fewer than most organisations first propose. Roles multiply naturally over time, so starting with a large number guarantees an unmaintainable model. Begin with the distinct job functions that genuinely differ in what they do, and add variations only where a real difference in required access justifies one.
Should IFS Cloud role design start from standard permission sets?
Usually yes. IFS ships baseline sets covering common functions, and adapting them is faster than composing everything from a blank page. It also tends to survive future releases better, because standard sets are maintained by IFS as the product changes around them.
How should IFS Cloud role design be tested?
By having real users execute their real daily tasks under their assigned access in a test environment, not by reviewing a list of permissions. Access problems are invisible on paper and obvious the moment somebody tries to work, so schedule at least two full cycles well before cutover.
IFS Cloud role design is cheap to do properly and expensive to retrofit
A role model takes workshops and a document. Rebuilding an access model that grew by exception over three years takes considerably more.
The organisations that find security straightforward are not the ones with simple businesses. They are the ones that wrote the model down before they configured anything.
Start there, and insist your partner does too.
Finally, treat the role model as a living document rather than a project artefact. It should be the thing somebody updates when a job changes, not a file that is archived at go-live.
Organisations that keep it current can answer an access question in minutes. Those that do not end up reverse engineering their own system from permission sets.