While working with a customer I was recently asked to assess the Granular Delegation capability introduced by ServiceNow (i think it was in Rome). With this came a few challenges that I want to highlight while working through the assessment
What happens to the existing delegate records declared using v1 legacy delegates once the Granular delegation is switched on?
The records declared using legacy delegate capability are maintained in 'sys_user_delegate’ table while declarations made with Granular delegation (com.glide.granular_service_delegation) are stored in 'sys_granular_delegate' table.
Now if you are a customer using Out of the box 'Employee Service Center' the configuration for your to-do page would query a utility class ApprovalDelegationUtil() and fetch your approvals as well as approvals of those for whom you are declared as a delegate
But you may wonder what delegation method would the system use? Well, you can define that by setting the system property 'glide.approval.delegation.version' to
- Either v1 to support only the prior service delegation features. This value disables support for granular delegation features.
- Either v2 to support only granular delegation feature. This value disables support for the existing service delegation features.
- Or v3 to support both granular and existing service delegation features. (default)
How to decide which version to choose?
This may depend on if you are using any form of delegation today?
1. if no, then it would be best to use the new Granular delegation and set the property to v2 this would mean you are using the most current functionality
2a. If yes, set the property to v2 (this would mean disabling v1 i.e. remove legacy declaration completely and migrate any existing records on sys_user_delegate table to new granular delegation in consultation with the user) [Recommended Approach may involve OCM too]
2b. Or Set the property to v3 this may not be a long term solution as from the user point of view it would be confusing to make declarations at 2 places while the system will always override v1 over v2 if the user and their delegates mapping is the same in both the applications thus, see below the error message while creating a granular delegation entry
This means for e.g. if the user 'Alex' has been declared as a delegate for a user 'Mike' using old delegation and if Mike again tries to make 'Alex' his delegate using granular delegation this won't work and Alex will end up seeing all records
With this, we decided to take approach 2a and were able to successfully sunset v1 capability
I hope this article helps those who are looking to explore something similar, please share your experiences in the comments to make this article better
1 Comment
