Hi

It is not something that is particulary easy to share, as these will differ between companies, depending on job roles, modules used, requirements etc... We use Apps 9, but I am guessing the methods of planning/building bespoke permission sets are similar, as they were for us in v7.5 and versions before that.

The temptation is to open the flood gates and grant more permission than is needed, 'to get the users going'. You could do that in Test, but still I think it is better to grant what you believe is required, then as the users hit issues during testing/training, deal with each case, and fine tune your Permission sets. It will be worth it in the end, and you wont need to be afraid when the auditors come round asking questions.

Do you have any working instructions? or Departmental training documents. This is what I would use to start to build Permission sets (End user roles). We have around 1-17 Permission sets per department, roughly divided by job role. Ensure the Permission set name or description is clear in what it allows.

I think keeping Permission sets as simple as possible whilst allowing you to ensure there are no segregation of duties conflicts is the best advice. And that 'Segregation of duties analysis' then is a useful tool to ensure what you have created is acceptable and secure.

Good luck.

Mike

Thanks Mike

Thanks for all the advice.

I was hoping for a bit of a “jump start” on some standard roles, but looks like there’s nothing out of the box I can use to that effect. The site I am working on has very few work instructions so we have an effort to create all of those too, but take onboard that we can create sets as we go. Definitely take on board your point to keep it simple and not open the floodgates. We have a lot of sensitive data so I need to be super careful with how I expose the different roles to data.

I’ve not worked in IFS before so wanted to understand the possibilities.

SOD conflicts are on my radar too, once I get the permissions sets resolved. Busy days ahead.

Thanks again

Alison

Is there a standard set of Roles and Permission Sets “Out of the Box” which is based on industry standards?  As an example, a user is given a Buyer Role; but they have read only access to Requisitions or read only access to receiving and other roles.  Does IFS have a Standard Matrixed Document that identifies the out of the box access for that role and the read only access to the other roles within the tool?  

Hello,

We recently implemented the APPS9 and from my experience :

1. Please make a list of roles 
2. List all the functions as per the roles
3. Create two columns for Full access and read only

Using above steps and  you will have a rough idea to grant the access. Grant those modules to specific permission sets and then start testing those permission sets. Ask SME to do their basic process testing in TEST environment.

In order to find certain API, I will recommend you to use debug conole.

What you can do is.. Start debug console and do the processs then you will get all the API name then you will either grant those API or block it.

For reports, Please make a list of all the operational reports as per the permission set and then grant it one by one.

Let me know if this helps.

I was hoping IFS had a matrixed spreadsheet that provided this information.

Hi Barbara,

i have generated the list of permission sets using the following query. In the below one i have listed out only the forms.

SELECT DISTINCT a.role, a.identity, c.description
                      FROM fnd_user_role a,
                           PRES_OBJECT_GRANT b,
                           PRES_OBJECT_DESCRIPTION c
                     WHERE     a.role = b.role
                           AND B.PO_ID(+) = c.po_id
                           AND b.po_id LIKE 'frm%'

I normally use the attached template generated from the Navigator.xml (this is from Apps 9) and use it with the workstreams to define the business roles.The dropdown for each object is Full, Read Only and Not Required. It’s a good start when defining the permission sets.