Skip to main content

Hi all,

 

How do you build your permission sets?

 

In the past we have granted things directly to the Enduser (EU) role.

Are there any downside of this? What is the meaning of using Functional (F) roles?

 

Now we have tried to make 1 F-role for every view/menu.

Granted presentation/database -objects / activities to these F-roles, and connected them to the EU role.

Found out that this was too complicated/detailed and we also experienced the “oracle 148 role limit” due to this.

 

Any best practices or examples of this?

 

Thanks in advance!

 

Regards,

K.

Hi @kwc ,

 

When we rolled out IFS Application 8 we also went back and forth how to do our permission sets.  We finally implemented creating functional permissions for high level functionality like viewing customer orders and creating / updating customer orders then we added those functional permissions to the end user departmental permissions.

 

Now that we have moved to IFS Application 10 we’ll be redoing our permission sets from scratch to support Aurena.   We are leaning strongly to just creating end user permission setups by functionality and assigning those to end users.  So we’d have an end user permission set called INCIDENT_REPORTING as an end user permission set and it would contain all the permissions we wish to give a user to support entering and updating an incident report.  Another example would be PURCHASE_AUTHORIZATION which would contain all permissions to allow a user to authorize purchase requisitions.  We believe moving to this model will be simpler to maintain and understand.

 

Regards,

William Klotz

As I see it, Functional Sets can be useful if you do a deeper structure.

For Aurena Native permission granting we have restricted that to End User Roles.

I think End User Roles only can be used, but it’s a matter of taste.

Thank you William and Tobese for sharing your experiences!

Terms & ConditionsCookie settings