I recently encountered an issue during the aggregation of an HR file where an identity was deleted. This identity was the owner of several objects, including Roles, Access Profiles and Governance Groups.
Consequently, this deletion led to put null pointers in the owner field of these objects, causing bugs during access requests process.
I attempted to manually reassign the owner through the interface, but this did not resolve the issue, since i had the same error ‘RoleAP id not found’. So i tried to recreate everything from scratch and it resolved the issue.
This experience leads me to a couple of questions :
1- Does IDN have any mechanisms to handle situations where the deletion of an identity results in null owner pointers for assosciated objects ?
2- If such a situation arises again, is there an alternative solution to completely recreating the objects ?
The best practice is to assign the owner of roles, access profile etc. as non-human identity (service account) or admin account. It is not recommended to assign owner as an user identity for those objects. The above case of yours can happen so most of the companies prefer using non-human identity as the owner so if the person leaves, it won’t effect any implementation. Have an admin account create for this specific purpose in IdentityNow Admins. In future, use that admin account as the owner while creating new objects such as roles, access profiles, etc.
Hi Amir, as Danish commented is recommended that owners are some group or identities from the Identity Admin source.
I think that you can avoid recreation of entire object, reimporteing it with the sp-config tool. I was trying it to clone some sources recently, and discovered that if I import the exported object on the same tenant, with some information changed, it overwrites actual content (renaming source or any other json object, like the “owner” attribute).
If best practice is to use non-human ownership of roles and access profiles, you lose the option to configure approvals to “owners”. Seems more appropriate to transfer ownership on termination via workflow than to use non-human account owners. But I guess this use case is HR hard deleting an account, not termination.
As jason said, the use of non-human as owners of roles and access profiles will make the client loose the option to configure the approval process to owners and in some cases if the manager is configured in the approval process and for some reason the identity doesn’t have a manager, IDN reassign the approval process to the role owner or source owner (depends if it’s a role or an AP) so it goes to the non-human owner