we have configured the the connection BTW IDN and SNOW via APP.
i have one query like… we have decided to have approval in SNOW. i know we have to configure the Approval Definition and Approval rules. but how to use them if we want to configure for multilevel approval.
for example
for one role there should be 3 level of approvals first role owner once he approve it should go for approval to manager and once he approve it should go for group approval. All 3 approval should be mandatory not like if any one approve it get approved? and it should go for next approval only when the first approval is approved.
Are you going to use this approval scheme across all access items or only specific ones?
It is possible to use different approval schemes for different access items, it’s just complicated to do so.
I looked into using the custom approval rules and found that they work, but the create each approval level all at the same time, which I did not care for.
If you want your approvals to be staggered, meaning not advancing to the next level until each level approves, you should just build your own ServiceNow workflow.
Edit: Those last two sentences were incorrect… give me a few minutes to make another post on how to do this.
Create your approval definitions and map them to the approval rules
Make sure you specify an order to the approval definitions if you want them to run in sequence. I made this mistake previously which caused all the approvals to be generated at the same time.
If you allow request for multiple access object types (Roles, Access Profiles, Entitlements), make sure you create approval definitions for each one. We currently only allow requests for access profiles, so I only had to create definitions for those.
Second one (Access Item Owner) requires a custom script since I have to make a call to the SailPoint API to find the owner. Once you find the owner on the SailPoint side, you have to look up their ServiceNow sys_id and set that as the return of the function
Then you have your approval definitions in order and mapped to their respective rules
thank you for explanation…i had done the same but issue here is when the first level approver approve it the next approval is going to state of no longer required and the RITM is getting approved and state is changing to fulfillment instead of waiting for approval for the second definition.
should i define anything anywhere i am missing anything?
Also in your second approver “Access Item Owner” is there any specific API to call? because in rule we have option called IDN onwer. can we make you of it?
There are a few reasons I don’t use “Access Item Owner”
Sometimes access items are owned by inactive identities (which we try to avoid, but it happens)
There are times access items are owned by our internal admin identity. This happened whenever we initially generated all our access profiles from active directory and the managedBy was a group or non-human account
We did a workaround to have a governance group “own” an access profile by using tags, so we had to use a custom script to make this happen
I also have a “fallback” option if the script can’t find an owner, and that is to assign the approval to our identity management team in ServiceNow
The issue still is that even after the order mentioned in the Approval Definitions. when the first-level approver approves the RITM, it doesn’t progress to the second-level approval stage. i even after setting ‘allsign’ to true, the issue remains unchanged. Are there any additional settings that need adjustment to resolve this matter?
Can you send a screenshot of the work notes in the RITM record where this is happening? That will usually post the approval rules/plan and if anything goes wrong.
This seems like an oddity, maybe there is a business rule on your sysapproval_approver table that’s doing this.
I would uncheck “All must sign” for a single user rule. In the UI, that checkbox disappears when you select “ServiceNow user”. “All Must Sign” indicates if there are multiple users in a single approval stage, they all must approve for it to move forward
Here are a few other things I would try if that doesn’t work
Try using a different ServiceNow user in your rule. Ensure they are not in the requested for or opened by fields
Try using a group instead of that specific user, but find a group where the user is a member
