Automatic Role Assignments of Employees

[Former Member]

Good afternoon

I was wondering how one would go about setting up automatic role assignments based on the position (extracted from HCM) of the person. As quoted from the 7.1 features guide document in the following link [] on page 51 it says that

IDM 7.1 will be able to

Automatically determine the business role of an employee, e.g. based on organizational assignment (job/position). Approve / verify this assignment via workflow.

One way that is obvious is using dynamic groups to determine which users belong to a certain role based on their position attribute and have this dynamic group autoassigned to the relevant role. This means that for every position you will have to set up a dynamic group, and have it autoassigned to the relevant business role, sounds tedious :(.

The other way would be to add an event task to the position attribute, so when the position value changes it triggers a task to remove the old business role and add the new one, how it  knows which role to add would probably be based on the position name, given that the business roles are set up to have the same name as the position name in hcm.

Am I on the right track? What other ways can you achieve automated role assignments?

Thanks and regards

Leo

[Former Member]

Leonard,

I won't try to tell you how you should do automatic role assignment, and I haven't seen specifically how it might work differently in 7.1, but having said that we have implemented automatica role assingments and I'll be happy to share with you how we've done it.

In our case (unfortunately) the business wanted us to determine the business role on a match to five fields from the HR record, so we weren't able to just put the position in the MXREF_MX_ROLE field. Instead, we used a lookup table that stored the five fields with the role they calculate to, then merged this with the feed we get from HR into a SQL view which we use a pass to load into IC.

To your specific case, you could just populate the Position value in the MXREF_MX_ROLE attribute flanked by "<" and ">" and this will do the trick. However, something to consider is how else users might be granted roles. Is the position based role the only role a user will get?

We have a base role that includes AD access, Email, ESS, etc. We have a supervisor role that is calculated with some business logic, and our users can request elevated (require approval) roles through workflow. This is where it can start to get a bit complicated. We set up several role entry reference attributes (Computer_User_Role, Elevated_Role, etc) to store the different 'varieties' of roles a user may have in our environment and then we have a process that mashes them all together - you can do this like:

MXREF_MX_ROLE = Computer_User_Role|Elevated_Role

However, then we get to your next point - what if the user's position changes? Now we want to remove one role from MXREF_MX_ROLE (the old position based role) and replace it with the new role leaving all other roles in place. We do this with a script - you may not need to do it at all if you have no other role types. If you simply want to replace one role with another in MXREF_MX_ROLE you can use the prefix ahead of the role name like: MXREF_MX_ROLE = <rolename>

As far as the trigger is concerned, I think you're on the right track to put the trigger on the Position attribute since that's what determines the role. There are other ways to do this, but from what you've described that seems like the way to go.

I hope this helps, please feel free to contact me if I can help further,

-Geoff

[Former Member]

Thanks Geoff, your reply was very helpful and certainly gave me a good idea of how auto role provisioning is set up. To me the overview docos for 7.1 seemed to insist that it handled auto role provisioning differently to 7.0. For now we ended up going with the simple option of provisioning the role based on the position id.

Cheers

Leo

[former_member205095]

Hi Geoff,

We are implementing the Business role based on position ID, however on the on going we notice that the amount of new positions is so high, in other words it need to create to many business roles,

we are thinks in alteranives such as cost center, organization unit,

do you remember what fields the business area suggested?

Arivind

[former_member188338]

Hi Geoff,

I agree with Arivind, position is 'normally' too find grained. We have used a collection of org attributes as criteria in dynamic groups, for about 10 key groups that have either high volumes, eg ESS/MSS or ones that change population frequently.

One thing to watch for is a "feature" of dynamic groups where they only pick up the first 1000 new members each time they are calculated. So if you create a group with 6500 members or add 6500 new members to an existing group you have to recalculate it 7 times for everyone to be correctly added.

Good luck.

Ian