A Practical Try at Change Request State Transitions via Virtual Agent

[sunkarasath]

This is something I implemented as a try‑out to change the states of a Change Request record using Virtual Agent. While working on this, I observed a few important policies and behaviors related to Change Request state transitions:

1. State transitions cannot move backward – once a Change Request moves to the next state, the previous one is not allowed.
2. Only the next valid state is available – the Change Request form shows only the immediate next state as an option.
3. Some state transitions require approvals – depending on the workflow, moving to certain states is blocked until the required approvals are completed.

Below are a few observations with change requests

FLOW 

FOR NORMALCHANGE_REQUEST

1. new to assess ---> fill the mandatory fields 1. assignment group
2. assess to authorize -------> from approval table approve all records which linked to this change then it automatically changed
3. authorize to scheduled  ----->  few more approval records are created after approving them (any one some cases) it changed to schedule
4. schedule to implement - -----> manual actions we made not compulsory , we directly moved to implement
5. implement to review -----> we moved it directly no actions needed
6. review to closed ------> moving to closed we write close code and close notes

FOR EMERGENCY CHANGE_REQUEST

1. in emergency no ASSESS state it move NEW to AUTHORIZE directly
2. NEW to AUTHORIZE ---------> we fill mandatory fields like assignment group thats it
3. AUTHORIZE to SCHEDULE-------> any one approval is enough among all approval records
4. SCHEDULE to IMPLEMENT -------> no actions needed basically ,  we change directly
5. IMPLEMENT to REVIEW  -----------> few change tasks are created close them all then automatically it moved to next state
6. REVIEW to CLOSED ---------------> update close notes and close code then change

FOR STANDARDCHANGE_REQUEST

1. in STANDARD change we don't have ASSESS and AUTHORIZE 
2. NEW to SCHEDULE              ------->   fill mandatory fields and change the state
3. SCHEDULE to IMPLEMENT  ------->    we change state directly 
4. IMPLEMENT to REVIEW      -------> few change tasks are created we have to close them all , then it automatically moved to REVIEW
5. REVIEW to CLOSED         ------> fill close code and close notes and change state to CLOSED

VA implementation :

1. if requester needs to change the state to next state then check the type of change and then based on type we create three branches

2. so when we change the state we need to do few actions mainly we need to do these. 

3. if approvals required for state transition , implement this code ---->

 4. sometimes one approval is enough so use IF instead of WHILE

5. some transition just need to update the other fields like assignment group , close code , close notes etc do with gliding change request table as below ---->

6. few change tasks are created we have to close then using code from  VA ----->

FEW POINTS ;

1.use gliderecordsecure

2.dont try to close the change requests directly 

there are some other policies , flow obstacles  and others stop the change transitions , if you observe those mention them. we can see they do with VA or not  ??