Change Lifecycle, a feature in Freshservice, is a representation of your service desk’s change process and lets you control all step-by-step transitions in change management. You can enforce various checks on all the change workflows, and have certain fields mandatory as the change progresses to the next transition state.


This can thereby deflect tickets, lessen risks, prevent duplicating efforts from failed changes, and enable your IT services adapt to evolving business needs.


Here's the list of default change types in Freshservice. You can edit the status and transitions for the following change types in the change lifecycle based on your organisation's requirements.


  • Standard Change: Changes that usually occur at regular intervals that are pre-planned, pre-approved, low risk, low impact, and don’t require the change advisory board (CAB) approval are called standard changes (for example, OS Upgrade).
  • Minor Change: Changes that don’t have a major impact, less risky, and undergo every stage in a change lifecycle, including CAB approval are called minor changes (for example, Website changes).
  • Major Change: Changes that can have a medium to high impact on ongoing business operations and may have financial implications that require CAB approval, as well as management approval, are called major changes (for example, Migration from one data center to another).
  • Emergency Change: Changes that need immediate fixes and emergency CAB approval, where the review is completed later to avoid potential risks are called emergency changes (for example, Security Patch).


You can also update the change types. Go to Admin > Service Management > Service Desk Settings > Field Manager > Change fields > Change type to enable/disable or change the names for different change types.

If your account has more than one workspace, go to Admin > {Worskpace Name} > Service Management > Service Desk Settings > Field Manager > Change fields.


Change Type in Freshservice

Later, you can also determine the statuses and transitions for the following change types.






The Change Lifecycle consists of:

  • Status: Any stage in a change management process (such as, Open, Planning, Awaiting Approval, and so on) is called a status.
  • Transition: The process of transitioning from one status to another (such as, Open to Planning) in known as transition.
  • Condition: The criteria that needs to be satisfied before there’s a transition from one status to another (for example, configuration of tasks need to be completed as a condition before Open to Planning transition) is known as a condition.


Supported conditions:

  • All Tasks on Change are complete - Checks if all the tasks currently present for the change request are complete.
  • Requested approvals are approved - In case of approvals requested, checks if the change is approved. 
  • Mandatory Fields - Make sure that the field data is present before allowing the transition.


To configure the change lifecycle:

  1. Go to Admin > Service Management > Service Desk Settings > Change Lifecycle. If your account has more than one workspace, go to Admin > {Worskpace Name} > Service Management > Service Desk Settings > Change Lifecycle.

  2. Choose any one lifecycle (for example, Major Change) from the list of lifecycles available.
  3. Click Edit to make changes in your Major Change lifecycle.
  4. For any change lifecycle, you will have an Open status by default; you can also add further statuses that need to be included in a major lifecycle with the Add new status option.
  5. To ensure your change lifecycle has a flow from start to finish, you can add transitions for each status with the Add transitions option for each status.
  6. While choosing the transition, you can set specific conditions, which need to be checked before the transition.
  7. Finally, you can save or publish your change lifecycle with the Save as Draft or Publish options.
  8. Once published, the lifecycle will be displayed above each change request for your agents to stay aware of the process.
  9. Also, the status options shown to agents will be limited based on the available transitions for the given status, so that agents do not deviate from the process.
  10. While editing the lifecycle, to get a quick preview of the lifecycle, click View Published lifecycle.
  11. If you wish to reorder your statuses, click Reorder and reorder your statuses.

     
  12. To delete a status, hover over the status and click Delete.



Based on the checks and conditions set in a Change Lifecycle, you can view its entire lifecycle.




Lock Fields in a Lifecycle


With this feature, change managers can now control which fields (for example, rollout plan) under a status (for example, planning) can be frozen, and the stage of a change request lifecycle.



Note:

  • If a change is closed or has reached the last status (for example, Pending review), and there's a change in its lifecycle (for example, minor change lifecycle), then the changes would only reflect in the upcoming changes (not in the existing changes).
  • If a change is in the mid-stage and there's a change in its lifecycle, then the changes would reflect only on new changes (not in the existing changes).
  • Also, if a lifecycle is deactivated, then the changes would only reflect in the upcoming changes (not in the existing changes).


Who can edit the change lifecycle?


Only users with permission to manage a change lifecycle can edit or delete the statuses or transitions in a change lifecycle.


Important:

  • In the change lifecycle, a status will only transition to the next status after all the conditions for the previous status are fulfilled.
  • Once the change has passed (for example, If Planning is completed), only the remaining statuses after planning (such as, Approval Request, Pending Release, and so on) will be listed under Status in the change.
  • This feature is available for all accounts with change management.
  • If you are already using change management, all applicable lifecycles are deactivated, so that your service desk’s ongoing operations are not impacted.
  • When a lifecycle is activated for the first time, it will not apply for changes that were created before its activation date.
  • When an active lifecycle is edited and republished, any change request midway in the lifecycle will only adhere to the previous version of the associated lifecycle.
  • Only new changes will follow the newly defined change lifecycle process.