Workflow recipe: Setting up a change management process wizard (IT example)

Overview

The Change Management Process Wizard is intended to be used by organizations that already have some sort of change management process in place and need to do some advanced tailoring (configuration, not customization) of Zendesk Support.

Step 1. What information would you like to gather about a change before it takes place?

To start out, identify the type of information you need to gather about a change to assess the change's risk, impact, and implementation plan for approval.

Think:

• Is the change against a specific technology stack?
• What's the business justification for making the change?
• Who is implementing the change?
• Will an outage be required?
• What's the outage duration?
• Who is impacted by the change? (Business Unit?  Global Region?  Site?)
• Does the change need to be completed by a certain date and time?
• Does the change need to wait until a certain date and time to be implemented?
• What type of change is required? (Standard? Minor? Major? Emergency?)

Only choose the fields that will actually help drive a decision on whether or not the change should move forward, help drive communication, or help report on specific metrics that have action plans associated with them.  There's always a high desire to track as much information as humanly possible about a change, but be realistic.  It's very easy to go overboard, when what you actually need for a change management process tends to be very simple.

Do:

For each piece of information you'd like to capture, create a new ticket field .

---

Step 2. Who is involved in your CAB / approval process?

Next, identify all of the groups of people that need to be involved in approving a change request.

Think:

• Do you have a formal Change Advisory Board?
• Do you ever require a business approval before implementing a change?
• Who (if anyone) needs to approve technology-specific changes?

Again, the fewer groups that need to review and approve a change, the better.  Err on the side of simplicity.  Change requesters are much more likely to follow a process that is streamlined and purposeful.

Do:

For each group identified, create a new group .  Next, add all of the potential approvers (these should be Zendesk users with an agent role) to their respective groups.

---

Step 3. What is your approval process?

Now it's time to think through your approval process.

It's a good idea to start by creating a single drop-down field that will track the overall state of approval for the change.  Go ahead and create a new field called "Approval State" (or whatever works for you), and add some options.  Requested, Pending Approval, Approved, and Rejected are recommended options for the Approval State field.

Do you have a single approval step in your process?

Brilliant.  Move on to Step 4.

Do you have multiple approval steps?

Are you sure you need multiple approval steps?  This is a really great time to whiteboard your process and look for waste.

It's best to have a custom drop-down field for each type of approval required in addition to the Approval State field to help drive workflow.  For example, if you have a technology approval and a CAB approval, you should create two more new fields:  Technology Approval, and CAB Approval.

Go ahead and create a new ticket field for each type of approval required in addition to the Approval State field you added earlier.

---

Step 4. What information drives your CAB / approval process?

Now that we have the basic structure in place to track change requests and where they are in the approval process, it's time to automate as much of the process as possible.  First, take some time to identify any rules that always hold true for your change management process.

Think:

• What types of changes are reviewed in CAB? (are emergency changes auto-approved?  what about minor changes?)
• Do all changes go immediately to CAB for approval?
• Do certain types of changes (perhaps by technology stack) need to be approved before the change gets reviewed in CAB?
• Do you have several approvals in parallel before going to CAB for approval?

Do:

This is a bit more art than science, so use your own judgement on this step.  For each "rule" above, create a trigger to automate that rule .  For example, you may decide to create a trigger that looks for any open minor change request with an Approval State of "Requested" and automatically set the Approval State to "Approved."  Or, you might look for any open major change request with an Approval State of "Requested" then assign that change to the CAB group and move its Approval State to "Pending Approval."

Example 1

	Conditions	Actions
TRIGGER 1	Status is New Change Type is Major Change Approval State is Requested	Status: Open Approval State: Pending Approval Group: CAB
TRIGGER 2	Status is New Change Type is Minor Change Approval State is Request OR blank	Status: Open Approval State: Approved
TRIGGER 3 (repeat for each group as necessary)	Status is Open Change Type is Major Change Approval State is Approved Technology is Unix Server	Group: Unix Server Support
TRIGGER 4	Status is Open Change Type is Major Change Approval State is Rejected	Status: Solved

If you have a multi-step approval process, create a trigger that first assigns the change to the first group whose approval is required.  Then create another trigger that will fire when the first group has approved (remember, we're going to track each approval step with a separate field), and automatically assign the change to the next group that requires approval.

If you have a multi-step approval process with parallel approvals, set up some triggers to look for all n approval fields to be approved, then automatically move the Approval State to "Approved."  Or, conversely, if you see at least one rejection, move the Approval state to "Rejected."

There's no one magic bullet for this, so determine what your simple process is, and then create triggers to automate the workflow.

---

Step 5. Extra Credit

One of the biggest questions we get is how to ensure that the right person is approving the change at every step of the way.  Naturally, you can always see who approves via the events audit log, but sometimes it's nice to have some other checks in place.

Macros

You can create personal or group macros for designated change approvers that allow them to approve in one click.  The macro can change the approval field itself, and also add a personalized comment to the ticket.  For example, the macro could apply the comment "Agent X approved on behalf of the Unix Server Team."

Email Approvals

You could also take your triggers a step further, and actually require approvals to come through email.  In other words, allow your approvers to respond to email notifications with "approve" or "reject" and have the triggers change the approval fields accordingly.