How to automate a request for change with workflows

By following a clear sequence of steps, you can ensure changes are evaluated, approved, and implemented with complete visibility and accountability.

With InvGate Service Management, you can standardize the way changes are requested and reviewed, and automate approvals and task assignments.

#1. Set up the request for change workflow

There’s a simple way to set up a Change Management workflow: just select the change request workflow template and customize it to your needs (you can download the workflow template preview from here).

1. Log in with an admin role, then go to: Settings > Requests > Workflows.
2. Select the Request for Change workflow from the list of templates.
3. Click Use template, and you’ll see the workflow in the Diagram Editor. Here, you can view and configure the workflow and the sequence of steps.

Tip: From Settings > Requests > Workflows, you can also create new ones from scratch (by clicking on “Add”), import workflows with the .sdw extension, or view and edit existing ones.

If the template is enough for your needs, you can use it as it is. If you need to tweak it, keep reading.

#2. Edit the change request workflow template

In the workflow diagram, you access the options that help define how the workflow behaves, who manages it, and what users see. You can double-click on any block to open its configuration and modify forms, tasks, approvals, and more.

Here’s what each block does.

1. Start form

   The process begins with a start form where the requester provides all the initial information needed to assess the change. You can add, remove, or modify fields and decide whether they’re mandatory.

   Default fields:

   • Type of change – Emergency, Standard, Normal.
   • Change description.
   • Reason for change.
   • Configuration item(s) involved.
   • Date and time of change.
   • Activity plan – Step-by-step outline of how the change will be executed.
   • Rollback plan – Actions to reverse the change if necessary.
   • Documents – Attach supporting files or technical documentation.

   Tip: Include only fields that add value to decision-making. Too many required fields can slow the process, especially for urgent requests.

2. Categorize the change type

   This is a conditional step, so the change follows the right review and approval path.

   • ECAB (Emergency Change Advisory Board) – For urgent changes that must be implemented quickly to prevent major incidents or address immediate business needs.
   • CAB (Change Advisory Board) – For standard changes that require detailed review and planning.
   • ELSE – Low-risk changes that can be approved with minimal oversight.
3. Risk and impact assessment

   Reviewers assess the change using two key factors:

   • Risk: High / Medium / Low.
   • Impact: High / Medium / Low

   These values can be used to place the change on a risk-impact matrix, helping prioritize review effort and determine approval requirements.

4. Approval (CAB/ECAB)

   The change request is routed to the appropriate approval group:

   • CAB for standard changes.
   • ECAB for emergency changes.

   For both cases, the possible outcomes are:

   • Accepted – The change moves to the implementation stage.
   • Rejected or canceled – The request is stopped, either because it does not meet requirements or priorities have shifted. In this case, an automated email notification is sent to the requester and stakeholders with the decision. As the final stage, a “canceled” step is triggered for the workflow.
5. Implementation

   Approved changes move into execution. This stage has a task list to follow. For each task, you can define: Name, description, due date, and responsible person.

   Other settings:

   • Allow new tasks during execution – Gives flexibility if unplanned steps arise.
   • Optional tasks – Lets the process proceed without completing all tasks.
6. Review

   Once implemented, the change is reviewed to verify the results:

   • Tasks were met.
   • Change was completed by the planned date.
   • No unintended side effects occurred.
   • Rollback is needed, yes/no.

   It also includes an open text field for outcomes, where reviewers can document detailed observations. This written record is valuable for audit processes or future reference, so change owners can anticipate risks or replicate successful approaches.

7. Rollback decision

   A conditional step where, based on the review, it will be determined if a rollback is needed:

   • Rollback – If the change caused issues or failed to meet objectives.
   • No rollback – If the change is successful.

   Tip: Always validate the rollback plan during the approval stage to avoid last-minute surprises.

8. Final step

   Depending on the rollback decision, the workflow continues with:

   • Rollback activities: A list of tasks to restore the environment to its prior state.
   • Notify change complete: An automated email notification to all stakeholders confirming completion.

Deploy your workflow

Once your change request workflow is ready:

1. Click on the save icon and return to the Workflows menu.
2. Click on Publish version to activate the updated workflow.
3. Then, assign it to a request category from the service catalog, in this case, “Change requests” under the corresponding department, IT.
4. Click Assign now to apply it.

Anyone using a change request from now on will follow this updated workflow.

Additional customization for your change request workflow

As we mentioned, in InvGate Service Management, every node in your workflow can be adapted to fit your organization’s policies and approval structure.

When tailoring a change request workflow, you’re not limited to the sequence shown in a template. You can:

1. Reorder stages – For example, move risk assessment before categorization if your organization prefers to evaluate scope first.
2. Expand forms – Include additional mandatory fields, such as cost estimates, vendor involvement, or links to related incident/problem tickets.
3. Add extra approval layers – For example, insert an additional review block for changes involving high-impact CIs.
4. Insert conditional steps – Create branches that skip unnecessary stages. For instance, bypass a full CAB review for pre-approved standard changes.
5. Email – Add automatic email alerts at points where stakeholders need to act or be informed (e.g., testing completed, rollback initiated).
6. Include integration points – Use Web Service blocks to update your CMDB, notify monitoring tools, or trigger scripts in deployment pipelines.