From Roles to Results: Best Practice for Permissions Testing and Environment Management in IFS

In our previous article, we explored an Example Structure for Functional and End User Roles in IFS using the two-layer model of functional and end user roles. That structure provides the foundation for clarity, reuse, and scalability.

But design alone isn’t enough. The real challenge comes when roles need to be tested, validated, and rolled out across environments. Without a disciplined approach, permissions testing can become chaotic, and environments can drift apart, leading to last-minute issues before go-live.

Recap: Example Structures

To start this discussion, let’s briefly revisit the main lessons from the last session:

• Functional roles are modular and mapped to navigator elements, not organizational units.
• End user roles are standalone, with no stacking or mixing required.
• Naming conventions (e.g., EU_ for end user roles, FR_ for functional roles) make structures transparent.

These principles ensure that testing has a stable starting point. Testing cannot succeed if the underlying role structure is inconsistent.

The Testing Lifecycle

Permissions testing follows a clear lifecycle with four stages:

1. Role Definition – work with project management and process responsibles to define high-level roles.
2. Pre-Testing – use dummy users to validate roles at a rough level.
3. Integration Testing – validate real processes in cycles using actual roles.
4. Go-Live – deploy stable roles to production.

Each stage builds on the previous one. Skipping or rushing through any step often leads to rework later.

1. Initial Role Definition & Setup

Testing begins with defining roles at a high level. Typically, project management and solution architects set the first draft, which is then refined with “permissions responsibles” from each process stream. These are usually process owners or key users who know the business needs in detail.

A good rule of thumb is to limit the number of end user roles to three or four per process stream at the start. For a project with ten streams, that gives roughly 30–40 roles initially. This number will naturally grow during implementation, but keeping it lean from the start avoids unnecessary complexity.

Setup in IFS can be time-intensive, especially if starting from scratch. Where possible, prebuilt libraries of functional roles accelerate the process significantly. Even if end user roles need to be newly created, modular functional roles provide reusable building blocks that reduce effort and ensure consistency.

2. Pre-Testing with Dummy Users

Once roles are defined and set up, the first testing step is pre-testing. This is not full end-to-end process testing, it’s a rough validation to check whether roles broadly align with expectations.

The approach is straightforward:

1. Assign one dummy user per process stream (e.g., Sales, Procurement, Finance).
2. Permissions responsibles assign one end user role at a time to the dummy user.
3. Testers log in with the dummy user, perform basic checks, and document issues.
4. Two guiding questions drive the test:
   1. Can I see everything I need?
   2. Am I blocked from things I shouldn’t see?

Issues are corrected in the CFG environment. If significant gaps remain after the first round, a second round of pre-testing may be necessary. The goal is not perfection but ensuring that roles are on the right track before integration testing begins.

3. Integration Testing with Real Roles

Integration testing is where permissions are validated under real project conditions. Most implementations include at least two or three cycles of integration testing, and roles should be part of each cycle.

• Cycle 1: Expect many issues. Permissions admins should be ready to fix small problems on the spot or grant temporary full access if needed.
• Cycle 2: Most users should now test with their real roles. Full access should be phased out as much as possible.
• Cycle 3: Roles should be stable, with minimal showstoppers. At this stage, permissions should be close to go-live readiness.

A crucial best practice is retesting. Every fix applied during a cycle must be retested before moving to the next cycle. Otherwise, issues risk being carried forward unnoticed.

Environment Management Best Practice

Testing doesn’t happen in a vacuum. Roles and permissions exist across multiple environments, and how those environments are managed determines whether permissions remain consistent.

A typical setup includes three environments:

• CFG (configuration) – where roles are defined, refined, and pre-tested.
• UAT (user acceptance testing) – where integration testing takes place.
• PROD (production) – the live system.

The golden rule: CFG is always the master environment.

1. Roles are defined and corrected in CFG.
2. Roles are exported to UAT for testing.
3. Any fixes discovered in UAT are consolidated back into CFG, not applied only in UAT.
4. Before go-live, roles are exported from CFG into PROD.

This avoids divergence, ensures consistency, and maintains a single source of truth for permissions.

Summary

• Start with process responsibles. They know the real needs and must be involved early.
• Use dummy users. They enable fast, focused pre-testing without jeopardizing main users.
• Phase out full access. By the second cycle of integration testing, most users should operate only with their assigned roles.
• Always retest fixes. Every adjustment must be validated before moving to the next cycle.
• Keep CFG as the source of truth. UAT is for testing, not for holding the master role definitions.

Part of a Continuing Series

This article builds on the previous post, “Example Structures for Functional and End User Roles,” where we showed how to design roles using the two-layer model. Here, we’ve shown how to test and manage those roles in practice.

The next article in the series will focus on handling presentation objects and projections outside of the Navigator and lobbies, highlighting the hidden permissions that often cause trouble.

Join the Next Session

Our next webinar we took a deep dive into permissions outside the Navigator. If your team has struggled with missing projections or unexplained access gaps, this session will be directly relevant.

As always, if you’d like to discuss your own testing approach or environment setup in more detail, get in touch. We’re happy to compare experiences and share lessons learned from real projects.