Ever wondered how Change Requests progress from one state to another, how Change Approval Policies are processed in Flow? - If the answer to either is yes, you are in the right place!
Let's start off with an overview of a Normal Change (as it is configured in the base system). Below is a diagram that depicts a normal change and how it can transition through its various states. It should provide a high-level overview of the parts that make up the state transitions of a Change.
Diagram 1
----
Now, let's pick out some key points of interest from the above diagram. Starting with the flow action Apply Change Approval Policy. How does this action process a given Change Request and then handle approvals? The following diagram aims to delve into this:
Diagram 2
Approval Rules are a syntax that are understood by the Ask for Approval flow action. The aim is to be able to define the criteria for an Approval to be satisfied based on the Decisions that have matched from the Change Approval Policy; these criteria can be defined as Approval Rules and then fed into the Ask for Approval flow action. The result is that the Ask for Approval flow action generates and manages the lifecycle of the approvals all within the Apply Change Approval Policy flow action, this complexity is not exposed, instead the outcomes of this flow action are the same as the Ask for Approval flow action.
With the outcome of the Apply Change Approval Policy action, we can attempt to progress the normal Change Request using the Evaluate Change Model flow action highlighted in the first diagram. As the name suggests, this is where Change Models come into play.
Our Change Request has the Normal Model associated to it and therefore it must abide by its specification of states and transitions. To ensure the Change Request progresses correctly, we execute the Evaluate Change Model flow action whenever we think an action can be taken. This flow action will evaluate the associated Change Model to see if we need to change the state of the Change Request, whether that's going in a positive or negative direction.
The Change Request that is provided to this flow action will be checked to find its current state, then possible automatic transitions for that state are factored. Once an automatic transition condition matches, the state value of the GlideRecord object representing the Change Request is updated. At this point, we have successfully evaluated the associated Change Model, and we can update the state of the Change Request record.
This post aims to clarify how Change Models, Change Approval Policies, and Flow work together to manage the lifecycle of the out of the box Normal Change. With the information provided in here you should be able to tailor your own experience to suit your own Changes.
