From Methodology to Practice: Example Structures for Functional and End User Roles in IFS

In our last article, we laid the groundwork for a best-practice methodology in IFS permissions management. The key message was simple: flexibility without structure leads to chaos. The two-layer model, functional roles holding permissions, end user roles bundling them, offers clarity, scalability, and maintainability.

But theory only gets you so far. This time, we move from concept to practice. Using a sales example, we’ll show how the two-layer approach translates into concrete structures: which roles to define, how to reuse them, and how to keep the whole setup transparent and auditable.

Recap: Why the Two-Layer Model Matters

Most IFS customers start without a methodology. Some rely on single-layer roles, embedding all permissions directly into end user roles. Others attempt nested structures, stacking roles within roles. Both approaches can work short-term, but both lead to complexity: duplicated permissions, unclear responsibilities, and messy audits.

The two-layer model avoids these pitfalls by separating responsibilities:

• Functional Roles contain permissions (projections, lobbies, workflows, reports, etc.).
• End User Roles contain only functional roles and are assigned to users.
  

This separation keeps the system flat, reusable, and easy to maintain.

Structure Principles in Practice

To see how this works, let’s consider an example from the sales area. Four principles guide the design:

1. Two-layer only: functional roles hold permissions, end user roles bundle them
2. Reusable functional roles: design them broadly enough to be reused in multiple contexts
3. Standalone end user roles: every end user role must work on its own without stacking
4. Optional separation of business and data roles: business roles focus on transactions, data roles focus on maintaining master and basic data

Example End User Roles

In our sales example, four end user roles cover both business and data responsibilities:

• Sales Director: full transactional access to sales, specific managerial lobbies, and limited read-only access in Finance (GL, AR)
• Sales Manager: similar to the director, but with slightly reduced finance visibility and no manager services
• Sales Master Data: create and maintain sales-related master data such as customers, contact details, price lists, and agreements
• Sales Basic Data: maintain sales-related basic data

A key point: all four roles include a basic IFS permission set. This ensures they are standalone, any one of them can be assigned to a user without requiring additional supporting roles.

Example Functional Roles

The next step is to define the functional roles that will be combined into these end user roles. This translation process starts from the requirements identified during role design workshops.

For example:

• Accounts Receivable Read Only (Finance)
• General Ledger Read Only (Finance)
• Purchase Order Read & Write (Procurement)
• Sales Master Data Read & Write (Sales)
• Sales Master Data Read Only (Sales)
• Sales Director Lobby (custom lobby package)

Notice the read-only vs. read/write variants. This is a practical way to provide differentiated access within the same domain without multiplying role definitions unnecessarily.

Consistency comes from naming conventions. In the example shown during the webinar, functional roles are prefixed with FR_, followed by a domain abbreviation (e.g., FIN for Finance, SLS for Sales), a description, and a suffix for access type (RO for read-only, RW for read/write).

Linking End User Roles to Functional Roles

The final step is bringing everything together in a matrix view: functional roles on one axis, end user roles on the other. Each end user role is simply a combination of functional roles.

This makes the structure transparent at a glance. It’s immediately clear which functional roles are reused, where overlaps exist, and how access is consistently assigned. It also supports audits, since the mapping between permissions and responsibilities is explicit.

Summary

The example demonstrates that the two-layer model is more than a best-practice guideline, it’s a workable design pattern that organizations can adopt immediately.

• End user roles remain standalone. Each can be assigned directly to a user without dependencies.
• Functional roles are modular. They are defined around navigator elements and reused across multiple end user roles.
• Naming conventions matter. Clear prefixes and suffixes make the role structure transparent and easier to maintain.
• Optional separation of business vs. data responsibilities can reduce overlap and clarify accountability, though it depends on the organizational setup.

Part of a Continuing Series

This article builds on our previous post, “Getting IFS Permissions Right: A Best-Practice Methodology,” where we introduced the two-layer model. Here we’ve shown what that model looks like in practice.

The next article in the series will explore permissions testing best practice and environment management, helping organizations validate and safeguard their role structures in real-world use.

Join the Next Session

In our next webinar we went deeper into testing and environment management for IFS permissions. If your team is moving to IFS Cloud or struggling with role audits, this session is especially relevant.

And as always, if you want to discuss your own role setup in more detail, get in touch. We’re happy to compare approaches and share our experience.