Functional vs End User Permission Sets

  • 25 August 2020
  • 4 replies
  • 1269 views
S
Rank
Userlevel 5
Badge +10

I know the topic of IFS permissions is never as black and white as we would hope, and each business may have a different view on how it should be implemented.

We are now required to comply with SOX due to US ownership, so Segregation of Duties (SOD) plays a big part in regular audits! In addition, the existing permission sets developed previously have become unmanageable for the team and is difficult to report on access to management or auditors. This has effectively triggered a re-build of our permission sets across our business. 

I have started to build new functional permission sets to group specific access together which is common across the business. For example, MANAGE_PUR_ORDER, MANAGE_WORK_ORDER, AUTHORIZE_PO, VIEW_SUPPLIER, APPROVE_INVOICE and MANAGE_CASE which within has all the relevant screen/database access for those areas. We know around Finance, HR and Payroll modules we may need to be more granular with the functional PS controls. 

These functional permission sets are then granted to end user permission sets for the various positions.

My concern is that due to the vast number of job positions and depts, we could end up with many end user permission sets all having similar structure subsequently creating a more complex and confusing model to manage going forward.

Also some positions may only have one individual, so you are effectively creating a permission set for one person which I am not sure is good practise. 

I am interested to hear others experiences or recommendations when it comes to building IFS permissions. 

Is there a best practise approach that is advised? What successful experiences do others have with permissions? Is the use of Functional and End User permission sets the correct approach or should we just use end user?

Look forward to hearing your views

4 replies

GPIE
Rank
Userlevel 5
Badge +11

Hi @SHAUN_KERSLAKE,

We only have a hundred users so our requirements are not as complex as yours.

For what it’s worth, we created functional process permission sets, e.g. create_requisition, create_purchase_order, create_shop_order, receive_shop_order etc. Then we built user roles such as Buyer, Junior_Buyer, Purchase_Manager etc and attach the functions they need to carry out. We have 30 custom user roles and 130 functional sets - sufficiently granular for now but will need more work in the future.

Good luck.

S
Rank
Userlevel 7
Badge +28

@SHAUN_KERSLAKE 

We are in the midst of a long journey doing the same thing.  We are converting old broad end user only permission sets to a combination of very granular functional permission sets that have a corresponding process document with them.  The only functions granted are the ones documented in the process document.  The sum of the functional roles then become the end user role for that area.  We refer to this as 3Pillars (permissions, process, training) - because the training comes after the first two are done.

We also have a hierarchical structure with some of them where a Senior Buyer for example or Operations Manager roll up the functions below.  So yes, we do have some users who end up with relatively unique groupings of functional roles, but the idea is to get the 80+% of the users into a standard grouping as much as possible.  Here is a view of the Operations Manager list, these are the process documents stored in IFS, but they have a 1-to-1 correspondence to a functional role.

3Pillars Ops Manager

The profiles for the majority of the users also end up being the same profile for nearly all users.  The profile is wide open, but then controlled via the permissions whether they can actually populate the screen with any data let alone perform any function on the view.

We expect to end up with roughly 250-275 functional roles with this methodology, but have a very robust control and ability to finely divide the processes. At the very least when we have a small organization that require the same person to have 2 of the 3 SOx affected roles, we know who they are and we make sure a local finance controller has an alternate method of auditing or validating compliance.  We always try to break the chain with at least separating one of the legs (e.g. purchasing, receiving, payment), so no one user can ever have all three.

 

We have a whole process around building and testing these roles and writing the documents, but I've never attempted to document the tenants of the process, it is just in my head.  It is a large project and requires a champion of the process who understands the business, understands the requirements of SOx, understands permissions and profiles, and has a vision of where you want to end up to make it successful.  It is a very slow and painstaking process when you get to involving the users and switching over from old to new permissions, so isn’t a quick and simple process.

Shawn

S
Rank
Userlevel 7
Badge +28

@GPIE

Good point on the users and complexity.

We have 830 users currently, soon to be closer to 1100.

3 manufacturing sites in 3 different countries

About 15 other sales and service sites that are still to be integrated.

And as I mentioned somewhere between 250-275 processes/functional roles.

GPIE
Rank
Userlevel 5
Badge +11

I don’t envy either of you!!

Reply


Terms & ConditionsCookie settings