Imagine if you couldn’t control the change processes within your organization. What mayhem would that be?
Change Lifecycle, a feature in Freshservice is a representation of the service desk’s change process and lets you control all step-by-step transitions in change management. You can also enforce checks on all the change workflows and also 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 have your IT services adapt to evolving business needs.
First, let's see the types of change in Freshservice
Here's the list of default change types in Freshservice. You can edit the status and transitions for the following change types in change lifecycle based on your organization requirements.
- Standard Change: Changes that usually occur at regular intervals which are pre planned, pre-approved and have a low risk, low impact and don’t require cab approval are called standard changes. (For eg. OS Upgrade)
- Minor Change: Changes that don’t have a major impact, which is less risky and undergo every stage in a change lifecycle including CAB approval are called minor changes. (For eg. Website changes)
- Major Change: Changes that can have medium to high impact on ongoing business operations and may have financial implications which require CAB approval ,as well as management approval, are called major changes. (For eg. 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 eg. Security Patch)
Apart from these, Freshservice also lets you add 4 other change types. To enable them, navigate to Admin -> Form Fields -> Change Fields and scroll down to Change type to enable/ disable or change the names for the following change types.
You could also later determine the statuses and transitions for the following change types.
Next, let’s see the process involved for each change
The Change Lifecycle consists of:
- Status: Any stage in a change management process (such as Open, Planning, Awaiting Approval, etc) is called a status.
- Transition: The process of changing from one status to another ( such as Open -> Planning) in known as transition.
- Condition: The criterias that needs to be satisfied before there’s a transition from one status to another (For eg: Configure that all tasks need to be completed as a condition before Open -> Planning transition) is known as condition.
- 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, check if the change is approved.
- Mandatory Fields - Makes sure that the field data is present before allowing the transition.
To configure change lifecycle
- Navigate to the Admin console -> Change Lifecycle in Helpdesk Productivity.
- Choose any one lifecycle(e.g. Major Change) from the list of lifecycles available.
- Click on Edit to make changes in your Major change lifecycle.
- For any change lifecycle, you will have a status called Open by default, you can also add further statuses that needs to be included in a major lifecycle by clicking the Add new status.
- To ensure your change lifecycle has a flow from start to finish, you can add transitions for each status by clicking the Add transitions in each status.
- While choosing the transition, you can set specific conditions which are to be checked before the transition.
- Finally, you can save or publish your change lifecycle, by clicking Save as Draft or Publish.
- Once it’s published, the lifecycle will be displayed on top each change request, for your agents to stay aware of the process
- 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.
- While editing the lifecycle, to get a quick preview of the lifecycle, click View Published lifecycle.
- If you wish to reorder your statuses, click Reorder and reorder your statuses.
- To delete a status, just hover over the status and click the Delete icon.
Based on the checks and conditions set in the Change lifecycle, you can now view the entire change lifecycle above that particular ticket. View the completion mark for the change that has passed and also see the current status which will be highlighted.
Lock Fields in a Lifecycle
With this feature, change managers can now control which fields (e.g. rollout plan) under a status (e.g. planning) can be freezed and when in the lifecycle of a change request.
- If the ticket is closed or reached the last status (for eg: Pending review) and there's a change in that ticket's lifecycle (for eg: minor change lifecycle), then the changes would only reflect in the upcoming tickets and not for the existing tickets.
- If the ticket is in the mid-stage and there's a change in that ticket's lifecycle, then the changes would reflect in both upcoming and existing tickets.
- Also, if a lifecycle is deactivated, then the changes would only reflect in the upcoming tickets and not for the existing tickets.
Who can edit the change lifecycle
Only a person with permission to manage change lifecycle can edit or delete the statuses or transitions in a change lifecycle. For access, navigate to Roles -> Agent Role (admin, SD Agent, etc) -> Administration below Permissions and Scope and check the Manage Change Lifecycle box and click Update.
- In change lifecycle, a status will only transition to the next status after it checks if all the conditions for the previous status are fulfilled.
- Once the change has passed (For eg. If Planning is completed), only the remaining statuses after planning (such as Approval Request, Pending Release, etc) will be listed under Status in your ticket.
- This feature is available for all accounts with change management.
- If you are already using change management, all applicable lifecycles are deactivated, so as to not impact your service desk’s ongoing operations.
- When a lifecycle is activated for the first time, it will not apply for changes which 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.