OasisPro · PermissionWorks · IFS Cloud · Go-Live · User Access Management
IFS Cloud permission sets at go-live.
Why they always cause problems. And how to stop that.
IFS Cloud permission sets at go-live are the most consistently underestimated workstream in every IFS Cloud implementation. They are also the most common cause of the frantic first two weeks of post-launch firefighting: users locked out of screens they need, approvers who cannot approve, operations staff blocked from transactions that the business ran on day one. PermissionWorks by OasisPro automates IFS Cloud permission set creation from real user navigation data and eliminates all of that.
The problem is not that IFS Cloud permission sets are inherently difficult to understand.
The problem is that creating permission sets manually at the scale of a real IFS Cloud environment is harder than it appears.
Covering every module, every role, and every navigation a user actually needs is a workstream that consistently gets underestimated in project planning and under-resourced at delivery.
By the time the project realises how much work is involved, the go-live date is fixed, the budget is committed, and the permission sets are either incomplete, over-permissive, or both.
IFS Cloud permission sets built from what users actually navigate, not from what a consultant thinks they navigate. That is the difference PermissionWorks makes at go-live.
PermissionWorks captures real screen navigation from your IFS Cloud environment and generates permission sets that match what users actually do, not what a theoretical role model assumes they do. It deploys in approximately one week, requires no IFS Solution Manager access, and continues working after go-live as new roles, new users, and new IFS Cloud releases introduce new navigations.
Why IFS Cloud permission sets at go-live consistently go wrong
IFS Cloud's permission set model is built around what users navigate inside the IFS Cloud application. Each permission set grants access to specific navigations, entities, and actions within IFS Cloud.
Get the permission sets right and every user can do exactly what they need to do from day one. Get them wrong and the help desk queue on go-live morning fills up faster than anyone can process it.
The manual approach to creating IFS Cloud permission sets starts with a role model. A functional consultant maps roles to expected navigations based on process design documents and workshops.
This produces permission sets that are theoretically correct but practically incomplete.
Process design documents do not capture the full breadth of what individual users actually navigate in their day-to-day work.
Users navigate IFS Cloud in ways that do not appear in any process design document. They check related records. They follow cross-module links.
They access supporting screens that the functional design assumed would be covered but did not explicitly map.
When those navigations are missing from the permission set, the user sees an access denied message on the first morning they try to do their job in the new system.
Theoretically correct, practically incomplete
Role model built from process design documents. Navigations mapped by functional consultants based on what users are supposed to do, not what they actually do. Missing navigations discovered on go-live morning when users hit access denied screens.
Post-go-live: help desk queue. Individual permission fixes. Inconsistent access across users in the same role. Security audit findings from over-permissive workarounds applied under pressure.
Built from what users actually navigate
PermissionWorks captures real user navigation within IFS Cloud during UAT and pre-production phases. Permission sets are generated from actual screen usage, not theoretical role models. Every navigation a user touches is included automatically.
Go-live: users can do everything they need from day one. No help desk queue for access denied issues. Permission sets are accurate because they reflect real usage, not design assumptions.
The most expensive IFS Cloud permission set mistakes are made in the final two weeks before go-live under deadline pressure.
When manual permission set creation falls behind schedule, the pressure to deliver something workable by go-live produces two failure modes. The first is under-permissive sets that lock users out of what they need, causing operational disruption on day one. The second is over-permissive sets that grant broad access to make the problem go away quickly, creating security and audit risks that have to be unwound during the post-go-live stabilisation period.
What makes IFS Cloud permission sets uniquely difficult to create manually
IFS Cloud's permission set model changed significantly from earlier IFS Applications versions.
Permission sets must cover the new IFS Cloud Aurena navigation structure, which is fundamentally different from the menu-based model in IFS Apps 10.
Every IFS Cloud release adds new navigations. Each 26R1 or 26R2 update introduces changes to the navigation structure that can invalidate existing permission sets or leave new areas uncovered.
A permission set that was correct in 26R1 may be incomplete in 26R2 without any deliberate change to the set itself.
IFS Cloud's security architecture is comprehensive and granular, which is exactly what enterprise security requires.
The same granularity makes manual permission set creation at scale an extremely time-consuming and error-prone process.
New Aurena navigation structure
IFS Cloud uses the Aurena framework with a fundamentally different navigation model from IFS Apps 10. Permission sets must be designed around Aurena navigations, not the legacy menu structure. This catches teams migrating from Apps 10 who underestimate the differences.
Every release adds new navigations
Each IFS Cloud update introduces new screens, new navigations, and changes to existing ones. Permission sets that were complete in the previous release may be missing new areas after an update. This requires ongoing maintenance that most businesses do not plan for at go-live.
Scale of manual mapping
A mid-size IFS Cloud implementation with 10 to 15 distinct user roles across Finance, SCM, Manufacturing, and EAM can involve hundreds of individual navigation permissions. Creating these manually takes weeks of specialist consultant time that most projects do not budget for correctly.
How PermissionWorks creates IFS Cloud permission sets from real user navigation
PermissionWorks takes a fundamentally different approach to IFS Cloud permission set creation.
Instead of asking a consultant to predict what every user role needs, it observes what users actually navigate and generates permission sets from that real data.
Navigation capture
During UAT, pilot, or pre-production phases, PermissionWorks captures every screen, entity, and action that users navigate within IFS Cloud. This builds a complete picture of real usage across every role in the environment.
Permission set generation
From the captured navigation data, PermissionWorks generates permission sets that include every navigation observed for each role. The sets are accurate because they are built from what users did, not what a design document said they should do.
Continuous maintenance
In Living Tool mode, PermissionWorks continues to monitor navigation and update permission sets as users access new areas, as new users join, or as IFS Cloud releases introduce new navigations. Permission sets stay current without manual intervention.
IFS Cloud permission sets built from real user navigation are more accurate, more secure, and faster to produce than any manual mapping approach.
The 3 PermissionWorks engagement models for IFS Cloud go-live
PermissionWorks is available in three engagement models designed to fit different stages of the IFS Cloud lifecycle and different levels of ongoing permission management need.
One-time: go-live or upgrade
PermissionWorks deployed for a single go-live or IFS Cloud upgrade. Captures navigation during UAT, generates the complete permission set library, validates against the target IFS Cloud version, and hands over clean permission sets ready for go-live. Ideal for implementations with a defined endpoint.
Living Tool: always-on
PermissionWorks runs continuously in your IFS Cloud environment. Permission sets are maintained in real time as users navigate new areas, as new users are onboarded, and as IFS Cloud releases introduce new navigations. The most comprehensive option for businesses that want permission management off their maintenance list permanently.
Tool plus specialist consultant
PermissionWorks combined with an OasisPro IFS Cloud security specialist who reviews the generated permission sets, resolves edge cases, advises on the security model, and ensures the output meets compliance and audit requirements. The recommended option for regulated industries and complex multi-entity environments.
PermissionWorks also covers full IFS Cloud user lifecycle management
Beyond permission set creation at go-live, PermissionWorks now includes full user lifecycle management for IFS Cloud environments, covering the operational user management that continues indefinitely after go-live.
- User onboarding: New starters get correct permission sets from day one based on their role and the real navigation data for that role, not a manually created template that may be out of date.
- User offboarding: Leavers are systematically deprovisioned from IFS Cloud with full audit trail. No permission sets left active for departed employees.
- Bulk user management: Role changes, department restructures, and site migrations affecting large numbers of users are handled through PermissionWorks automation rather than manual one-by-one permission updates.
- Access reviews: Scheduled access reviews with complete visibility of who has what permissions across the IFS Cloud environment, exportable for audit and compliance purposes.
- Audit trail: Every permission change tracked with timestamp, user, and reason. Complete audit trail for ISO 27001, SOC 2, and industry-specific compliance requirements.
PermissionWorks works alongside CrystalWorks, IFS Cloud consulting, and the rest of the OasisPro IFS Cloud product suite.
If you are planning an IFS Cloud go-live or upgrade, OasisPro can address permission sets through PermissionWorks, Crystal Reports continuity through CrystalWorks, and the broader technical and functional workstreams through senior IFS Cloud consultants. One partner, all the workstreams that consistently cause problems at IFS Cloud go-live, addressed together rather than separately.
Full PermissionWorks overviewIFS Cloud go-live permissions. Automated. Accurate. Done in a week.
Talk to OasisPro about PermissionWorks. We will assess your current IFS Cloud environment or upcoming go-live scope and confirm which PermissionWorks engagement model delivers the right permission set coverage for your project.
Why do IFS Cloud permission sets fail at go-live?
IFS Cloud permission sets fail at go-live when they are built from theoretical role models rather than real user navigation data. Process design documents do not capture every screen a user actually navigates in day-to-day operations. Missing navigations are discovered when users hit access denied screens on go-live morning, triggering a wave of help desk tickets and emergency permission fixes that disrupt the stabilisation period.
How does PermissionWorks create IFS Cloud permission sets differently?
PermissionWorks captures real user navigation from within the IFS Cloud environment during UAT and pre-production phases. It generates permission sets based on what users actually navigate rather than what a consultant maps from a process design document. The resulting permission sets are more complete and more accurate because they reflect real usage patterns.
Does PermissionWorks require IFS Solution Manager?
No. PermissionWorks does not require IFS Solution Manager access, which makes it usable for IFS Cloud customers who do not hold Solution Manager licences. OasisPro deploys PermissionWorks within your IFS Cloud environment without any dependency on Solution Manager.
How long does PermissionWorks take to deploy?
PermissionWorks is typically deployed and generating its first permission sets within approximately one week of onboarding. This is significantly faster than a manual permission set creation project for a full IFS Cloud environment, which typically takes several weeks of specialist consultant time.