This article summarizes the core content from a recent webinar, focused on one central question: how should IFS customers structure their permissions to avoid chaos and ensure scalability? It is part of our ongoing series of blog posts that run in parallel with our webinar program. The first article in the series covered the 6 Major Limitations of Permissions Management in IFS – And How to Work Around Them. The lack of methodology was one of the limitations presented there and was expanded on in this webinar and blog post.
One of the defining features of IFS is its flexibility. Permissions can be modeled in many ways, giving administrators freedom but also exposing them to complexity. Without a clear methodology, structures tend to grow organically and eventually become bloated. It is not uncommon to see organizations running hundreds, or even thousands, of end user roles, many of them redundant or only slightly different from each other. Over time, this makes auditing, troubleshooting, and scaling a constant challenge.
During the webinar, we reviewed three common strategies. Some organizations rely on a single-layer setup, where all permissions are embedded directly into end user roles. This approach is simple to start with but quickly becomes hard to maintain and nearly impossible to reuse. Others experiment with nested structures where roles are placed inside other roles – sometimes with or without clear rules. While technically possible, this design often becomes opaque, creating confusion about where permissions originate and making debugging unnecessarily time-consuming.
The third strategy, the two-layer model, strikes the right balance. It is the approach we recommend, and the one that consistently leads to scalable and sustainable results.
The two-layer model draws a strict line between two types of roles:
• Functional roles contain the actual permissions, such as projections, lobbies, workflows, and other access rights. They are designed as modular building blocks that can be reused across the system.• End user roles are the bundles assigned to employees. They contain only functional roles, never direct permissions.
This separation keeps structures clear and makes the system easier to audit. When a new permission is needed, it is added to a functional role, which can then be attached to one or more end user roles. End user roles themselves stay clean and job-focused.
A few guiding principles bring this model to life:
One of the most practical insights from the webinar came from benchmarking real-world projects. Companies that adopt the two-layer model typically end up with 30 to 60 end user roles, and between 100 and 250 functional roles. Functional roles are reused multiple times across end user roles, while each end user role typically combines a dozen or so functional roles.
These numbers are not rigid rules, but they do provide useful guardrails. If your organization has thousands of end user roles, it is usually a sign that permissions have grown without structure and that a restructuring is overdue. Conversely, if you find yourself with only a handful of very large roles, that may indicate that users are receiving far more access than they actually need.
Reports and lobbies deserve special attention. They often cause frustration because they don’t behave like other permission objects.
Reports, such as Quick Reports or Business Reporter reports, are technically projections. The best way to handle them is to group them logically into functional roles. For example, all procurement-related reports might sit together in one functional role, which can then be reused by different end user roles.
Lobbies, by contrast, are their own type of permission set, but they often depend on projections. A lobby tile showing KPIs will usually link to pages or data sources that require their own access rights. The best practice is therefore to package each lobby together with its related projections into a single functional role. That way, users don’t end up with dashboards that display empty tiles or broken links.
The message is straightforward: flexibility without structure leads to chaos. A two-layer approach, built on reusable functional roles and clean end user bundles, delivers the clarity and scalability that IFS customers need.
This model makes permissions easier to audit, easier to maintain, and far more resilient to change. It is not just a way to organize roles more neatly; it is a way to reduce risk, improve compliance, and simplify day-to-day administration.
This post follows our first article, “6 Major Limitations of Permissions Management in IFS – And How to Work Around Them,” and sets the stage for the next installment: “Example Structure of Functional and End User Roles.” That upcoming piece will translate the methodology described here into a real-life example.
In our next webinar we went through real-world example structures for functional and end user roles. And if you’d like to discuss your own role setup in more detail, don’t hesitate to reach out – we’re always happy to exchange experiences and compare approaches.
