Save Hours Managing Your IFS Permissions

The purpose of this document is to explain, in the simplest and most concise way possible, a complex subject found in every ERP system: rights management.

This document is based on version 23R1, but remains compatible with later versions up to 25R1 (verified).

Here, we will describe the IFS standard. If your version has been modified (in the “M” sense by IFS), some elements may differ between this document and your version.

Rights management includes several aspects:

• Understanding the IFS rights system across the different components.
• How to assign these rights to users.
• Managing module-specific rights.

We will cover each of these aspects in detail throughout this document so that nothing is left unexplained!

To maximize value for you, each section includes a “Our Recommendations” chapter. These insights come directly from our experience with clients, so don’t skip them!

Introduction

There are several categories of rights:

• Rights to projections (pages and buttons)
• Rights to lobbys
• Rights to workflows
• Rights to database tasks
• Rights to database tasks chains
• Rights to system privileges

 Permission Sets

Permission sets are of two types:

• End User Role
• Functional User Role

Projections can be assigned to permission sets of both types.

This will make no difference.

The main difference between these two types is that only End User Roles can be connected to users, but we will come back to this later.

End User Roles and Functional User Roles are provided by IFS.

Two strategies are available to you:

• Analyze those provided by IFS and build on them.
• Create your own permission sets.

Whichever option you choose, it is strongly recommended to stick to only one, otherwise access management can quickly become complex to maintain.

An exception to this rule: the End User Role “FND_WEBENDUSER_MAIN” must in any case be used, whatever strategy is chosen. It is the baseline permission for each user that allows access to the application.

⚠️ Important: in IFS, the broadest permission always prevails.

For example, if you grant Read-Only rights in one permission set and Write rights in another, and both are linked to the same user, the broader right, Write, will apply.

​

  Our Recommendations

If you choose to work with customized permission sets, here are some recommendations we can give you.

1. Use a global permission set

It is useful to create a global permission set where you can attach the FND_WEBENDUSER_MAIN mentioned above, as well as other rights that can be generic for all users, such as:

• CreateMultipleDocumentsHandling, to allow users to attach documents to the different objects they can access.
• CustomPagesHandling, and more specifically the right to clear the “mapping cache” for the user. This is handy in production to make user support easier.

2. Limit the addition of projections to a single type of permission set

“Simplicity is the ultimate sophistication.”

This quote is not ours but Leonardo da Vinci’s, and we could hardly advise you better than to follow it to the letter.

The interlinking of permission sets can quickly become confusing.

IFS does not impose any constraints on how permission sets and added rights are used. You can add rights to an End User Role, to a Functional Role, link one End User Role to another End User Role, a Functional Role to another Functional Role…

As you can see, without a clear process, things can quickly get out of hand.

Our recommendation is to limit the addition of projections to a single type of set:

• Either you use both types, and in this case restrict the addition of projections to the Functional Role.
• Or you use only the End User Role.

This will make it much easier to analyze where a user’s right came from, especially if you want to remove it.

​

​

Specific Description of Rights Management

Rights to Projections

To obtain rights on a page or on certain buttons within pages, these rights are granted in IFS through a projection.

A projection contains a set of rights, so a single projection can provide access to multiple pages, tabs, or buttons.

It is not possible to give an exact number of projections, but they are counted in the hundreds, if not thousands. These projections are generated directly by IFS. It is strongly discouraged to add or modify them.

Example of a projection:

A right to a projection can be granted as Read-Only, Full, or Customized.

The Read-Only right prevents any action of creation, modification, or deletion on the objects within the relevant pages.

The Full right provides all permissions: read, create, modify, and delete.

It is also possible, through the Projection Grants screen, to customize rights. This customization allows you to refine permissions depending on the screens, for example on specific features or buttons.

This can be done via the sub-tabs Entity Action Grants and Projection Action Grants.

A concrete example: for a business opportunity, it is possible to restrict the right to change the opportunity status without preventing users from editing other information related to the opportunity.

Regarding pages, there are two types: Pages and Assistants.

A Page is a standard page, such as sites or customers:

An Assistant is a page that guides the user through a sequence of steps (recognizable by the breadcrumb trail at the top):

How to Link These Rights to Users  

For a user to obtain a right in IFS, they must be able to access the projection.

This is done via the permission sets, as explained above.

For a user to gain access to a permission set, there are two possible ways:

• A direct assignment via the user.
• An assignment via user groups.

The choice is yours, but our recommendation is to use groups as much as possible, since they are easier to manage.

As a reminder, a user or a user group can only have access to permission sets of the type End User Role.

Below is a diagram illustrating the overall logic described above:

💡 User group management can be delegated through a third-party service such as Azure Active Directory, for example. You then only need to assign the user groups to the appropriate permission sets, while all user and group management can remain fully integrated into your company processes.

  Our Recommendations

• Use user groups

This will allow you to manage rights more easily by group rather than by individual users.

If audits ever need to be carried out, it will also be simpler to analyze a user’s access.

• Minimize overlaps of rights

Avoid as much as possible having user groups with multiple End User Roles nested within each other if you are using Functional Roles.

Also avoid using user groups if you are assigning access directly to users — otherwise, stick to recommendation 1!

• Align with your company’s organizational structure

For user groups, stay as close as possible to your organization.

If you have a Sales department, name your user group so that from the name alone you immediately understand who may belong to that group.

• If you use all four levels… Don’t!

See the recommendation in the “Permission Sets” section.

 ERP Control - Manage your IFS rights (much) faster, with full autonomy

As you’ve seen in this guide, managing user rights in IFS is critical, yet often time-consuming and complex.

That’s exactly why we created ERP Control.

➤ Simplified rights management in just a few clicks

➤ Fast actions, no tickets, no waiting

➤ More autonomy for business teams, less dependency on IT

ERP Control, designed by IFS users, for IFS users.