I am preparing a role A which has role B as subcomponent. I would like to get approval from role B business owner to add it to role A. However when I add "dynamic - role owner" to approval node as approver it is resolved to role A business owner instead of role B business owner.
Also if I add a group C as well as subcomponent then the "object - group: owner" is resolved to group C owner. Unfortunately there is no "Object - Role: owner" choice, only "Object - Role: Last Reviewed Date" and "Object - Role: Name".
Has anyone any idea how to overcome this issue? Is there any best practice?
All doable, all done before.
As a general remark, if you split by a category and have a sub flow that splits then by that category ONLY CRIs (change request items) that HAVE a category will get processed by any instance of the subflow. That can come in super handy as you then only provide the items for approval that are relevant for those approvers.
Also, depending on your use case you may need to do several splits after another. So split by one category, start the approval sub flow, come back up, split again differently, sub flow again and so on. This makes it possible for the sub flow definition to be one and the same for all those different approvals, it just gets presented he CR in different slices and in turn puts those in front of the different approvers.
Let's say you want to do a split for the role_owners:backup_owners in a CR for the INDIRECT roles, so the roles contained within roles that directly get assigned.
You need to
a) prep the split
b) start a sub flow that splits by "category"
for a) prep the split
In the below example we "group" each CRI (change request item) that is of type "GlobalRole" and that gets added or part of a role create. You could of course remove that part of the WHERE clause to include all kinds of entitlement types. The OPERAND in a CRI is the element that gets modified and the VALUE is what is happening to it. In the below example you would provide the owners:backup_owners of the INDIRECT roles (we select the VALUE_TYPE GlobalRole) their elements (their global roles) for approval.
b) inside the sub flow you need to deconstruct the split criteria
(which we so cleverly set as the owner:backup_owner in the previous step)
Use these two workflow variables (job level) to assign the approval task to. The cool thing here,
If you want to split differently, have a look at this:
Split by the "target" role, or the direct role (for role management request, we use the role versions here...).
Similar to above, but now we are looking at it from the OPERAND, so at the role that got modified.
Split by target role owners:backup_owners but display the the user members only for approval:
Here the OPERAND are the Users that get added.
That's pretty much it.
Frank