Solved

Functional vs End User Permission Set Uses

  • 9 June 2023
  • 4 replies
  • 510 views
L
Rank
Userlevel 4
Badge +11

I was wondering if anyone could explain the core difference between functional Role permissions and end user role Permissions and maybe an example of how they are used.

 

We are needing / wanting to better control IFS Permissions so I am wanting to create permissions based on Business Roles so all the Service Advisors will have the same permissions, the supervisors will have the same permissions etc.

Would that be Functional or End User or am I required to create both?

Thanks, 

icon

Best answer by AussieAnders 9 June 2023, 12:20

View original

4 replies

DNVMDEL
Rank
Userlevel 1
Badge +4

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.

 

#

Step

Who?

1

Define Groups of Functional Roles

Draft by functional consultants

2

Define End User Roles based on actual Business Roles

Draft by Denys (MD)

3

Fill Matrix

Joint effort (also with experts/KeyUsers)

4

Define & set up functional role permission sets type with their projections/lobbies

Technical+Functional consultant

5

Link functional role permission sets to End User (Business) role permission sets according to Matrix

TBD (Technical consultant and/or Denys ICT)

6

Finetune ongoing based on testing

  

 

Maxime Deleye - Denys - IFS Application Manager
Link
Rank
Userlevel 7
Badge +22

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.

Kind regards
L
Rank
Userlevel 4
Badge +11

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

Thanks, 

A
Rank
Userlevel 3
Badge +7

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.

Reply


Terms & ConditionsCookie settings