How to best simulate the HCM position structure via Entry Type?

[Former Member]

Hello all,

We have a situation with IDM (7.2 SP6), where we are attempting to simulate a 'role to position' assignment internally within IDM.  ie we want an entry type to represent the position object that should replicate positions in HCM that we can then assign Roles and Persons to.  Initially we attempted using the MX_ROLE entry type for both position (ie ROLE:POSITION...) and business role (ie ROLE:BUSINESSROLE....) using the differing name format.  Unfortunately we experienced a number of issues with our workflows and approval as Role->Role is considered a 'structural' relationship with MXREF_MX_ROLE and MXMEMBER_MX_ROLE as opposed to an 'assignment' so no pending value is generated, validity is difficult and the approval becomes poisonous.  Any thoughts to correct this would be appreciated?

With the above situation in mind, I attempted to use the MX_GROUP entry type to simulate the position object, and linked roles and persons to this.  In the short term, we had pending values created and approvals working nicely, though inheritance was now the isse as the MX_PERSON was not inheriting the roles indirectly via the Group.  The other problem we had here related to the actual use of the group object and all the implied links to AD provisioning....too much heartache.

So, next attempt is to use a newly defined entry type Z_POSITION.  This is my first attempt on this, and while the entry type and attribute creation seems simple enough, I am struggling with activating the entry type via the UI.  How can I activate the maintenance of the new entry type in the 'Manage' tab, such that it is accessible in the 'Show' dropdown?

Your assistance with the individual Qs would be appreciated, in addition to your thoughts on the best concept design to achieve the position object described above.

Cheers

Andrew

[Former Member · Accepted solution]

Thanks for the feedback! Really appreciate it.

We really need to ensure that there is no manual intervention other than assigning 'role' to 'position', which will always be manual and will require approval.  In addition, both the role and the position need to be able to 'exist' independently of each other, so defining one or the other as an attribute on the other will not suffice.

I have a second post which refers to SP8 as a possible solution (ID Mgmt 7.2 SP8 attribute validity) as apparently validity dates would be possible, and hence a PVO for role to role assignments.  Do you know if thjis is the case?

Kind Regards,

Andrew

[Former Member · Accepted solution]

Hi Andrew,

   My suggestion is to make a mapping table(you will need two columns for position and BR), as in your case you would need to update the table you can make a custom UI(this UI will be visible only from a users with administrative rights) and job to maintaining the table(this job will be executed from the UI, after the new file is updated with a new role added to a position). So from here you will have a trace who is made the update and when(you can add a mandatory field for the reason-why).

After you have done that, before BR assigning you have to check according to the user's position, which BR is correct from the mapping table.

BR,

Simona

[former_member190695 · Accepted solution]

Hi Andrew,

Unfortunately there 's no best practice for your requirement. I see a lot of things in your post that you should carefully pay attention to such as using MX_GROUP entry type for NON-LDAP based group membership If you intend to use the default SAP Framework. Anyway, I did a similar thing as follows:

1- Create a custom Entry Type for HCM Positions.

2- Load HCM Positions into IDS and save the data using the custom entry type in step 1.

3 - Create a custom attribute (MX_ROLE) and assign 1 or more positions (Position Id) to it

4- If you are using the HCM LDAP Extract, calculate which Business Role(s) should be assigned to a user by looking up the MX_FS_POSITION_ID on MX_PERSON entry on the Business Role(s) (MX_ROLES) based on the custom attribute in step 3.

5- If you assign an Approval workflow (MX_ADD_MEMBER_/VALIDATE_TASK the system will create a PVO as per your requirement.

Regards,

Ridouan

[ivan_petrov · Accepted solution]

Hi Andrew,

gave you a very basic example on how to relate position to role.

Of course it is possible to extend the scenario by using more than one role for position, or/and using context dependent business roles, or/and using role inheritance.

Of course you should be much more specific in details about your scenario in order to receive much clear explanation what and how it should be done

I personally have even better custom solution that gave you the opportunity to have unlimited number of key combinations as a base of certain role assignment and even unlimited number of properties to set this relation. If you interested of demo just post me a status update message.

And about validity dates these were always in the game - even in earlier versions.

Best regards,

Ivan

[Former Member · Accepted solution]

Hi Ridouan,

What you describe in your post is exactly what we have done in scenario 3 above, where we have a new entry type for 'POSITION'.  The one remaining piece of the puzzle is step '6' in your post....ie after the approval and PVO and the subsequent assignment of the ROLE to the POSITION.  I just struggle there with inheritance to the PERSON.  Is there a job/task required in the ordered group after this point to get the ROLE that is now assigned to the POSITION onto the PERSON? ie there is no auto inheritance in place. I assume a simil;ar job would need to remove any inheritance after the validity expired or a removal request was made.

PERSON <-> POSITION <-> ROLE <-> PRIV

???????????????????

I am sure I am missing the simplest of things, but your help would be appreciated.

Cheers

Andrew

[Former Member · Accepted solution]

Hi Andrew

As discussed, on SP6 you can use a 'temporary' attribute to undertake the approval and then assign the valuse across to MXREF_MX_ROLE when the approval is granted.

This will avoid the basic approval problem of the attribute assigning despite not being approved.

Peter

[former_member190695 · Accepted solution]

Hi Andrew,

In my scenario I am not using inheritance: Position --> Person. The Business Role has a custom attribute that holds 1 or more position Id's. In HCM Staging we calculate the Business Role(s) that needs to be assigned to an identity based on the attribute MX_FS_POSITION_ID on the user profile. This could be any of the HCM attributes. It's basically a one-to-one relation but it's at least automated.

Be careful with this approach as an HR clerk may create 100 new positions per day, so you need to have a plan how to deal with and identify new positions.

Regards,

Ridouan

[Former Member]

Hi Andrew,

  My suggestion is to use MX_PERSON attribute(MX_POSTION) and to make a mapping between the Business Roles and the Position. You will have  to create a table where you will make a mapping between the positions and the business roles. Then on every modify on the attribute MX_POSITION you will call a task whre you have to first check for the assigned position - the correct BR form the mapping table and after that to assign the BR.

BR,

Simona

[terovirta]

My suggestion is to use MX_PERSON attribute(MX_POSTION) and to make a mapping between the Business Roles and the Position. You will have  to create a table where you will make a mapping between the positions and the business roles. Then on every modify on the attribute MX_POSITION you will call a task whre you have to first check for the assigned position - the correct BR form the mapping table and after that to assign the BR.

If you want to do such mapping, probably easier way would be to have a custom attribute in the MX_ROLE (multivalue if needed) that would list the positions for the role. That way the positions that enable access would be visible (and maintainable) in the IdM UI and you wouldn't be depending on temp tables. Plus any further config you would do will be easier when the data is accessible in IdM attributes.

[Former Member]

Hi Tero,

  I see where are you going, but the easiest maintenance will be with a mapping table(not temporary) and you will be able to modify this table veri easy, just have to create a job that will read from a CSV-file and write into the table. So every time you have to update the mapping between the position and BR, you have  to update one CSV-file.

BR,

Simona

[terovirta]

 I see where are you going, but the easiest maintenance will be with a mapping table(not temporary) and you will be able to modify this table veri easy, just have to create a job that will read from a CSV-file and write into the table. So every time you have to update the mapping between the position and BR, you have  to update one CSV-file.

Depends naturally on the requirements (which we don't know) and who'll do the maintenance etc. But after the initial data load Excel-maintenance + having someone to run an import job is pretty awkward when you can enable "business" (HR vs security folks depending again on the customer organization) people to do it themselves instead of manual steps.

[Former Member]

Hi Tero,

  You are right, but it is not a problem to run the job from the UI, as well a validations can be made before the data from the file to be written into the mapping table. All of that depends of the case if there are going to be frequently changes on the mapping between position and BR or who will do the mapping.

BR,

Simona

[Former Member]

Thanks Peter,

I have the new entry type, 'Position' operating correctly and displaying through the UI.  Unfortunately I come back to the original problem, where despite now creating a PVO and having approvals workflow correctly when assigning my roles to this object, the users associated with the position are not inheriting any of the assigned roles or subordinate privs.  It takes me back to the same situation I had when trying to use MX_GROUP....ie no inheritance.

Is there any way I can amedn inheritance via configuration to impact objects other than the role hierarchy?

ie scenrio 1:

using role as a positin object.  Has inheritance, though approvals are the stumbling block as no PVO is generated when assigning a role to a role.

scenario 2:

using the MX_GROUP type as a position. PVO and approvals OK, but no inheritance and too many other integration interdependencies.

scenario 3:

creating a non-std position object.  PVO and approvals OK, but no inheritance.

I am currently looking at creating a task after the approval to copy the role assignments from the position object to the MX_PERSON....

Cheers,

Andrew

[Former Member]

Hi Andrew

If you want the object to appear in the search list in the UI, click 'Searchable Entry Type' on the entry type general tab.

Peter