An individual Functional Role seems to be a specific page or screen in IFS.
As I understand it you group actual authorizations to acces or write on pages in Groups of Functional Roles. (See my last screenshot).

You define individual End User Roles based on your Business Roles.

You then link the required Groups of Functional Roles to each End User Role.

And then you link specific Users to their correct End User Role (permission set), so Users are not directly linked to (Groups of) Functional Role(s) (Permissions sets).

Alternatively for this last step, you can link End User Roles, or directly Groups of Functional roles to a User Group, and then these will be granted to a User once that user is added in that User Group.

My reply from a precious similar topic can also further help:

This old IFS Community thread on the community was also helpful to me. It describes the iteration process to setting things up. It is a manual process via the PermissionSetNavigatorTree in my screenshot.

Our complete process involves below steps where the functional roles (step1) and linked setup (via the screenshot step4) is assisted by our implementation partner.

Hi @lisa.gilesAB 

you can’t assign a functional permission set (screen create user) directly to a user. You need to assign it to a enduser permission set and assing this enduser role to the user. The navigator on the screen create user is clearly structured.

Thanks @DNVMDEL, I am using Apps 10 is it the same concept / principles?

Thanks, 

The only technical difference is that End User Roles can be granted to user - hence the names - whereas Functional Roles cannot. The purpose with Functional Roles is to build a hierarchy of permissions, although both types can be granted to other permission sets.

At a bare minimum, you only need End User Roles. However, if there is a reasonable amount of overlap between what different users need, I generally recommend having:

1. Functional Roles that represent business processes, such as “enter purchase requisition”, “approve purchase order”, “register arrival”, “enter supplier invoice” etc.
   • This is where you would grant IFS features (i.e., presentation objects, projections, lobbies etc.)
2. End User roles that represent positions and individual may hold, such as “procurement officer”, “warehouse worker”, “AP assistant” etc.
   • These would in turn contain functional roles
   • Some functional roles may be shared by many end user roles, e.g., “enter purchase requisition” may be relevant for a wide range of positions, from inventory to HCM
   • You can grant IFS features directly to these, but I would recommend not, just to keep it clean.

That’s just one way of doing it though, so I could recommend:

• Be consistent, whichever approach you take
• As always, keep it simple. It’s easy to get lost in detail. (I have seen customer installations with more permission sets than users, indicating that something went wrong somewhere.)
• Give “your” permission set a specific prefix to (in name or description), to make them easier to identify, since there are a plethora of system defined permission sets (which are not marked as such).

Finally a couple of technical details:

• Everyone needs the permission set FND_ENDUSER in IFS Applications, or FND_WEBENDUSER_MAIN in IFS Cloud, which contains very basic permissions like access to log on.
• FND_CONNECT has a misleading name, and is not for connecting to IFS, but only for the integration framework user IFSCONNECT (pet peeve or mine).

I hope that helps, and please feel free to ask more questions if you want.