ITSM change management tow levels of approval using approval policy and flow designer

[VaranAwesomenow]

This article is to implement two levels of approval sequentially during authorize phase for a change request as part of change management process.

Code : anilvaranasi/Custom-CHG-Approval

Normal change management process flow as per ServiceNow best practices provided in nowcreate process guide. I have added some now create content screenshots to set the context and background on what is offered OOB and how to implement this requirement of multiple sequential approvals. Actual solution details are covered as we navigate along the article.

Implement Business owner and IT owner approval as sequential approvals 

Change requests should go through two levels of approval sequentially during Authorize state, first level will be IT application owner, and second level will be application platform owner. 

Customization needed: Create following objects meet this requirement 

1. Deactivate OOB flow -> Change - Normal – Authorize 

1. Create new flow -> Change - Normal - Authorize Two Level Approval 

1. Deactivate OOB approval policy , policy decision -> Requires CAB Approval 

1. Create two new answers 

1. Change Approval Definition: Authorize Platform owner Approval 

1.  

1. Change Approval Definition: Authorize Application owner Approval 

1.  

1. Create two new policy decisions 

1. Requires Application Owner Approval and associate answer as Change Approval Definition: Authorize Application owner Approval 

1.  

1. Requires Platform Owner Approval and associate answer as Change Approval Definition: Authorize Platform owner Approval 

1.  

Once above setup is complete on a given change request when the state is in authorize, two levels of approval will get triggered sequentially, first level approval will be application owner and second level approval will be platform owner. 

Testing 

Test Service AMEA Customer Portal, where Level1 -> IT application owner -> Managed by -> Abraham Lincoln and Level2 -> Platform owner -> owned by -> Abel Tuter 

Create new change with service as test service 

Request approval on assess state approvals get set to assignment group (this is OOB no change is done) 

Approve the change request. 

Once change moves to authorize then level1 (IT application owner , Abraham Lincoln approval will be triggered) 

Once approved as Abraham Lincoln, second level approval Platform owner -> owned by -> Abel Tuter is triggered 

Once approved change moves to scheduled state 

Below is the flow execution for above change 

[David Nottingha]

This is nice but there are no details on the Flow Designer flow - Can you share what you changed in the flow to enable to two stage approval?

[VaranAwesomenow]

ty @David Nottingha  for the feedback I will update the relevant details, but if you would like to look at the code, i have added link to the scoped app anilvaranasi/Custom-CHG-Approval

[Balakrishna E K]

Hey @VaranAwesomenow 

It's an insightful information... even I'm trying to add Additional approval group to the standard & Emergency change, and I have created the things as you have shown but once I raise a request my required approvals are not triggered. What will be the issue? Or Should I need to modify the backend workflow also??
If so, then please help me out...
Thanks in advance.

[frankapoth]

One Issue you may have with this approach is that deactivating the OOTB flows will permanently disable them as they are in read-only protected mode. Once disabled, there is no way to re-enable them. Unfortunately, if they are not disabled, they will always fire when the OOTB Normal change model is used. There are two possible work-arounds. One is to create a new change model to go with the custom flows, completely side-stepping the original model and flows. The other is to somehow use the existing OOTB flows and Normal change model. The approval level can be tracked in a custom field on change_request, and business rules can re-trigger the OOTB flows by preventing state progression based on the custom field value and updating the record. Business rules could probably also be used to prevent automatic state transitions if the approval levels haven't been satisfied. The drawback to this approach is obviously the custom field and business logic that blocks state transitions, but it would allow the OOTB flows and models to be used with very little additional overhead.