How to run a change advisory board (CAB) in Zendesk

Zendesk's built-in approval requests, triggers, ticket forms and custom fields give you a workable base for simple change approvals. You can capture a request, collect a sign-off and keep the work on a ticket your service desk already uses.

Once changes need risk-based routing, several approvers, a change window and a post-implementation review, you'll want more structure around that record. That's where SweetHawk comes in: a workflow layer that sits on top of Zendesk and lets you go further in each of these areas. In this guide that means Approve for the CAB decision, Tasks & Subtickets to raise a change from the problem or incident that caused it, Field Rules for a proper Change ticket type and Calendar for the change window, with Recurring Tickets for the quarterly change that comes round every time, Future Tickets to schedule a change six months out from today's problem ticket, and Notify and Timers to keep the whole thing moving.

This guide shows how to run a change advisory board in Zendesk, from evaluation through closure: what Zendesk gives you to start with, and where each SweetHawk app adds to it as your process grows.

Key takeaways

• Use a Zendesk ticket as the change record, from initial assessment through post-implementation review, and evaluate risk, impact, rollback and timing before asking the CAB to decide.
• Approve runs the decision: route by risk, chain approvers in sequence or parallel, and set thresholds such as any three of five CAB members, with reviewers responding from email, Slack or Microsoft Teams.
• Tasks & Subtickets raises the change from the problem or incident ticket that caused it, even for an emergency change, with a template that picks which fields carry across and reshapes them with Liquid markup. The two tickets stay linked.
• Field Rules gives you a Change ticket type. Zendesk's native Type field has Question, Incident, Problem and Task, so add your own Ticket type field with Change in it, keep the native field in step behind the scenes, and show agents just the one.
• Calendar puts the change window on a shared change calendar, so you can see what else is scheduled before you propose a time, and syncs to Google Calendar and Microsoft 365 for people who don't use Zendesk.

What a CAB actually does

A change advisory board, or CAB, brings the right people together to assess a proposed change before implementation. Its job isn't to approve every ticket: it's to make a defensible decision about whether a change should proceed, under what conditions and when.

Change evaluation means checking the affected services, business impact, technical risk, rollback plan and proposed timing. You want answers to practical questions: who could lose access, how will you detect failure, and can you restore service within the window?

• Standard changes are repeatable, low-risk changes that follow an agreed, pre-authorised procedure.
• Normal changes need assessment and authorisation appropriate to their risk and impact.
• Emergency changes need an accelerated decision, often from a smaller emergency CAB, followed by a review.

For most CABs today, the review is asynchronous rather than a weekly meeting. Reviewers read the same record and respond when they're ready; a meeting is useful when there's disagreement or a difficult trade-off.

What Zendesk gives you out of the box

Zendesk gives you a solid foundation for the change record. Ticket forms and custom fields capture the service, owner, risk, proposed date and implementation notes in a consistent format.

The native Type field has four values: Question, Incident, Problem and Task. Change isn't one of them, so you have two good options. You can identify change requests by a dedicated change form and custom fields, with views and reports filtering on the form, which works well for a simple process. Or you can use Field Rules to create your own Ticket type field with Change in it, hide the native field and keep it set correctly behind the scenes, so a change is typed as a change and the native behaviours still work. The Field Rules section below shows how, and this walkthrough has the exact steps.

Built-in approval requests suit straightforward single sign-offs, and approvers don't need a paid agent seat: end users decide from the help centre, agents from Agent Workspace or Slack, and everyone is notified by email. Triggers and automations support routing and follow-up, while side conversations let you loop in people outside the ticket.

On Suite Professional and Employee Service Growth plans and above, Zendesk also has native task lists: one reusable checklist per ticket, up to 20 items, which can be made required before solve. Since October 2026 a task can create a subticket by hand, one level deep, carrying the subject, comment, assignee and requester. For a single flat implementation checklist on a change ticket, that may be all you need. We've compared the two in detail in Zendesk task lists vs SweetHawk Tasks & Subtickets.

Explore gives you reporting on the ticket data you collect. Together, these tools are a sensible starting point if your change process is small, your approval path is simple and your service desk already works in Zendesk.

Running the change process in a Zendesk ticket

Capture the change record

Start with a change form containing the affected service, change category, risk, impact, implementation plan, rollback plan and proposed window. Give reviewers enough information to decide without chasing the requester.

With Field Rules, show or hide fields based on other fields, agent role, group or brand. Require a rollback plan when risk is high, and make trigger-populated values read-only.

Give Zendesk a Change ticket type

Zendesk's Type field offers Question, Incident, Problem and Task. With Field Rules you can work around that cleanly: create your own Ticket type dropdown with Change alongside the native values, add a rule that hides the native Type field from agents, and add rules that set the hidden native field behind the scenes whenever your field changes.

Agents see a single Ticket type field, with Change in it. Behind the scenes the native field still holds Incident or Problem where that matters, so incident-to-problem linking and task due dates keep working, and your Explore reports can use either field.

The setup is three rules and takes a few minutes. We've written it up step by step in Can I add additional ticket type options in Zendesk?, and the help centre has the matching field mapping guide for the rules themselves.

Raise the change from the problem or incident

Most changes start life as something else: a problem ticket that needs a fix, or an incident that needs an emergency change right now. Zendesk's native subtickets can link the two if someone creates the child by hand and fills it in. With Tasks & Subtickets, a task on the problem ticket creates the change ticket as a linked subticket, so the change always points back to what caused it and the problem shows the change that resolves it.

The difference is what arrives. The subticket template decides what the change ticket looks like: its form, requester, assignee and every field on it, not just the subject and a comment. You choose which fields carry across from the parent and how they're reshaped on the way, using Zendesk placeholders and Liquid markup. The affected service copies straight over, the problem summary becomes the reason for change, and the risk defaults to the parent's impact unless someone changes it. Nobody retypes anything.

For an emergency change, the same task on the incident ticket creates the change ticket in seconds with the incident details already on it, and the emergency approval path can start from a trigger the moment it exists.

Evaluate and route by risk

Agree your approval policy before configuring it. For example, a low-risk change might need a service owner, while a medium-risk change needs that owner, a CAB decision and final authorisation from the change manager.

Approve starts approvals from a Zendesk trigger or a Zendesk Action Flow, so any flow you build can fire an approval, and routes them conditionally using fields such as risk, impact, category or region. You can build sequential, parallel or mixed chains and set thresholds such as any three of five CAB members.

Approvers can come dynamically from ticket, user or organisation fields. Exclude the requester from approving their own request, and set deadlines, reminders and escalation to a backup approver.

Ask reviewers to assess the plan, not just select an answer. Approve keeps every decision, comment and response channel in an audit trail, with a visual approval timeline on the ticket.

Schedule the change window

Place the change into an agreed window using Calendar. A shared change calendar inside Zendesk shows every change already scheduled, in day, week or month views, so the requester can see what else is landing that night before proposing a time, and the CAB can see the clash before it happens. Reschedule by dragging the event.

Events can be created by a trigger, and two-way sync with Google Calendar and Microsoft 365 means the change window shows up in the calendars people already look at, including stakeholders who have no Zendesk access at all. Event times are written to ticket fields, so you can use them in views, triggers and Explore reports, and timezone support helps teams coordinate across locations.

Implement with a phased task list

Use Tasks & Subtickets to turn the approved plan into a reusable checklist. Apply a template automatically by trigger, then separate pre-implementation checks, implementation steps and post-implementation validation into phases.

The next phase appears only when the previous phase is complete, so nobody starts implementation before the checks are signed off. We introduced this in multi-phase task lists, and the help centre guide on creating phased task lists walks through the setup. A task can create a linked subticket with its own form, fields and assignee when another team owns part of the work.

Make the task list required so the ticket can't be solved with unfinished tasks. Task counts are written to ticket fields and can be reported in Explore.

Keep it moving

Use Notify for pop-up alerts to the right agents or groups when an approval arrives, an approver hasn't responded or a stage stalls.

Use Timers to give each stage a named timer with its own business hours schedule and ticket escalation when time runs out. Keep these stage targets distinct from Approve's decision deadlines, so you're tracking both review time and delivery progress.

Review the result and close

Record the actual outcome, validation results, service impact and whether rollback was needed. Compare those results with the original evaluation: did the change behave as expected?

Start a second approval for the post-implementation review, and include the review work in a required task list. Your closure procedure should check both the review decision and completed tasks, leaving the evaluation, approvals and implementation record together on the ticket.

An example: a normal change with a CAB review

Suppose your network team proposes a routing change affecting a business application. Here's how that normal change moves through Zendesk:

1. A problem ticket traces repeated outages to a routing fault. A task on that ticket creates the change ticket as a linked subticket, with the affected service, the problem summary and the impact carried across by the template. The network engineer adds the implementation steps and rollback instructions and sets risk to medium.
2. A Zendesk trigger starts a three-step approval: the service owner first, then any three of five CAB members, then the change manager.
3. Reviewers assess the risk and plan, responding from Microsoft Teams and email. Their decisions and comments appear on the ticket.
4. Once approved, the change is scheduled into Thursday's window on the shared change calendar. The scheduled times are also recorded in ticket fields.
5. The task list moves through pre-implementation checks, implementation and validation. A linked subticket assigns application testing to the application team.
6. The implementer records the result and starts the post-implementation review approval. After that approval and completion of the required tasks, the ticket closes with the change history recorded.

The CAB doesn't need another meeting just to read out those decisions. If a reviewer raises a concern about rollback, resolve it on the record before proceeding.

When Zendesk alone is enough

Start with native Zendesk tools when your process fits them. You may have everything you need if:

• Each change needs one straightforward sign-off, handled through built-in approval requests.
• Your change volume is low enough that an owner can coordinate timing directly.
• A dedicated ticket form and custom fields capture the information reviewers need.
• Triggers, automations and side conversations cover your routing and follow-up.
• One flat native task list per change, with the odd hand-made subticket, is enough implementation tracking.
• Your reporting questions can be answered from ticket data in Explore.

There's no benefit in adding several apps to reproduce a simple process that's already working.

When you need more than that

Add structure when the process starts depending on someone remembering the next step:

• Risk or impact changes who must approve, with sequential stages or a voting threshold.
• CAB members include people with no Zendesk account at all, such as vendors or business owners, or people who want to decide by replying to an email or from Microsoft Teams.
• Changes are raised from problem and incident tickets and you want the data carried across and the tickets linked, rather than retyped.
• You want Change as a ticket type, not a form name, without losing what the native Type field does.
• You need a shared change calendar, calendar sync and scheduled times available in ticket reporting.
• Implementation spans several teams and needs phased, required task lists, several lists per ticket, subtickets created automatically with the right form and fields, and task data in views, triggers and Explore.
• You need approval reminders, backup approvers, stage timers and a recorded post-implementation review.

Every app here comes in the SweetHawk Suite, so one trial covers the lot. Teams typically switch on Approve and Tasks & Subtickets first, then Field Rules and Calendar as their change management in Zendesk process develops.

Frequently asked questions

Can you run a CAB in Zendesk?

Yes. Use a Zendesk ticket as the change record, with forms and custom fields for evaluation, built-in approval requests for simple sign-offs, and triggers for routing. For a multi-stage CAB process, SweetHawk adds conditional approval chains and voting thresholds (Approve), changes raised from problem tickets with linked subtickets (Tasks & Subtickets), a Change ticket type (Field Rules) and a shared change calendar (Calendar). You can keep the request, decisions, implementation record and post-implementation review together on the ticket.

Do CAB members need a Zendesk licence?

No, with either route. Zendesk's native approvals let end users approve from the help centre without an agent seat. SweetHawk Approve goes a step further: approvers don't need a Zendesk account of any kind, and they can decide by replying to an email, from Slack, from Microsoft Teams or in the Approve web portal. That lets you include vendors, business owners and other reviewers who will never log in to Zendesk. Each decision, comment and response channel is recorded in the approval audit trail on the ticket.

How do you handle emergency changes?

Define an emergency category and route it to a smaller emergency CAB using Approve's conditional routing. Set decision deadlines, reminders and escalation to a backup approver rather than waiting for the normal review cycle. Keep the essential risk, impact and rollback information on the ticket, even when time is short. After implementation, record the outcome and run a post-implementation review.

How long does it take to set up?

Setup is typically days, not months, because your team is already in Zendesk. Start by agreeing the change fields, risk categories, approval owners and implementation checklist. Then configure one normal-change path and test it before adding more routes. Teams typically begin with Approve and Tasks & Subtickets; a 14-day free trial of the SweetHawk Suite covers every app in this guide, so you can test your process first.

Where to start

If you're deciding how much structure your CAB needs, book a call and we'll talk through your approval paths and change windows. Or start a 14-day free trial of the SweetHawk Suite, which includes every app in this guide, install Approve first and test one normal-change workflow before adding the rest.