🔐 OasisPro · IFS Cloud Security Model · Apps 10 Upgrades · PermissionWorks
Your Apps 10 access design
does not come with you.
IFS Cloud security model design is the workstream that quietly turns a well-planned Applications 10 upgrade into a late one. Everyone budgets for functional configuration. Everyone budgets for integrations. Data migration usually gets its own lead. Then, somewhere around the first serious round of user testing, somebody discovers that the access design refined over a decade in Apps 10 does not transfer, and it has to be built again from nothing.
Extended support for IFS Applications 10 ends in March 2028, so a large number of organisations are scoping this work right now.
Most of their plans have a single line for security. These are the 6 truths worth knowing before that line becomes a quarter.
Access models are invisible until somebody tries to do their job. That is why the gap is always found in user testing, and never in design review.
A permission model reviewed on a spreadsheet looks finished. The same model tested by a real planner running a real day surfaces problems within an hour. This is not a failure of diligence, it is a property of the work: access design cannot be validated by inspection, only by use. Which means the discovery always lands late unless testing is deliberately scheduled early.
The 6 truths about the IFS Cloud security model
- 1. The mechanism is genuinely different. IFS Cloud grants access through permission sets tied to projections, actions and data. Applications 10 worked through presentation objects. Concepts overlap, implementations do not.
- 2. Granularity cuts both ways. The precision is a real feature, and it is why the volume of decisions is so large. Precision multiplied by role count is what makes this a workstream rather than a task.
- 3. Your role model is the actual deliverable. Not the permission sets. If nobody has written down what a planner, a buyer or a warehouse supervisor genuinely needs to do, no amount of configuration will rescue it.
- 4. Standard sets are a better starting point than a blank page. IFS ships baseline permission sets covering common functions. Adapting them is faster, safer, and survives future releases better than composing everything yourself.
- 5. Testing has to use real tasks. Not a review of the model. Real users, real daily work, in a test environment, at least twice, well before cutover.
- 6. Somebody has to own it after go-live. Roles change constantly. Without a named owner, access drifts within months and the model stops being explainable.
Security is one of four things that do not carry across
The same Applications 10 upgrade brings three other surprises. Crystal Reports leaves the platform entirely at 26R2. Custom events and integrations built against older structures need reworking against OData projections. And data migration is a business decision exercise, not a technical one. Plan all four together or each will be discovered separately, late.
What a planned IFS Cloud security model workstream looks like
It starts in parallel with functional design rather than after it, because access requirements fall directly out of process decisions.
It produces a documented role model first, agreed with the business, before anybody opens a configuration screen.
It composes access from small reusable blocks aligned to functions, rather than building a bespoke set per individual, which is what keeps it maintainable.
It schedules two full test cycles with real users, and treats blocked work as the signal rather than as a defect to be argued about.
The IFS Community and the IFS documentation site both cover the underlying security concepts in detail.
Our IFS Cloud permissions guide sets out the 6 fixes that keep the work under control.
The IFS Cloud security model is not harder than the old one. It is differently shaped, and larger in volume, which is a planning problem rather than a technical one.
Sizing the IFS Cloud security model work honestly
Three questions determine the effort, and none of them is about how many users you have.
How many genuinely distinct job functions exist? A business with twelve clear functions is a different exercise from one with sixty variations grown by exception.
Are those functions documented anywhere? If the answer is that people know them, the first phase of the work is writing them down, and that takes workshops rather than configuration time.
Who can decide? Somebody has to be able to say what a buyer is permitted to approve. Without that authority the IFS Cloud security model work stalls regardless of who is doing it.
Answer those three and the estimate becomes defensible. Skip them and any number you are given is a guess dressed as a quote.
What happens if the IFS Cloud security model is left until testing
The work does not disappear, it just arrives compressed and at the worst possible moment.
Testing slows because users cannot complete the scenarios they were asked to run, and it becomes impossible to tell whether a failure is configuration, data or access.
Training suffers, because people learn a system that behaves differently once real permissions apply.
And the stabilisation period after go-live gets consumed by access tickets rather than by the genuine teething issues it was reserved for.
None of that reflects badly on IFS Cloud. It reflects a plan that gave a workstream one line.
Three signs your IFS Cloud security model plan is too thin
The plan says "configure permissions" with a duration attached but no named business owner. That is a task line pretending to be a workstream.
Access testing appears only inside general user acceptance testing rather than as its own cycle. Access failures will then be logged as functional defects and argued about.
Nobody has asked how many distinct job functions exist. Without that number, the IFS Cloud security model effort has not been estimated, only assumed.
Any one of the three is worth raising before the plan is baselined, because all three get considerably more expensive once a go-live date is committed.
PermissionWorks removes the repetitive part of the rebuild.
It generates and validates candidate permission sets from your role definitions and real screen navigation, cutting roughly 80 percent of the manual effort. Your team reviews and approves rather than building line by line, and no IFS Solution Manager access is required after integration.
See where security fits in the wider Apps 10 upgradeFind out how big your security workstream really is.
Send us a handful of your real job functions. We will show you what generated IFS Cloud permission sets look like against them, how the review process works, and what that means for the security line on your upgrade plan.
Does the IFS Applications 10 security model transfer to IFS Cloud?
Not cleanly. IFS Cloud grants access through permission sets tied to projections, actions and data, which is a different mechanism to the presentation object model used in Applications 10. Some concepts map conceptually, but the practical outcome for most organisations is that the access model needs designing again rather than migrating.
When do most projects discover the security gap?
During the first meaningful round of user acceptance testing, which is usually far too late to absorb comfortably. Until real users attempt real tasks, an access model looks complete on paper. The work then lands in the weeks that were reserved for stabilisation before cutover.
How much effort should be budgeted for the IFS Cloud security model?
It scales with the number of distinct job functions rather than headcount. A business with a dozen clearly defined roles is a manageable exercise. One with sixty variations, undocumented and grown by exception over a decade, is a workstream of its own and should carry a named lead and its own gate.
Can any of the IFS Cloud security model rebuild be automated?
The repetitive part can. Generating candidate permission sets from role definitions and real screen navigation is pattern work at volume, which is what PermissionWorks addresses, cutting roughly 80 percent of the manual effort. Deciding whether the resulting access is right for your business stays a human judgement.
Budget the IFS Cloud security model before testing budgets it for you
Every organisation moving from Applications 10 faces this. The difference between the ones that find it manageable and the ones that lose a quarter is whether it appeared on the plan at kickoff.
Give it a role model, a named owner, two real test cycles, and automation for the repetitive volume.
Then it is a workstream rather than a crisis.