Change approval groups control who signs off on production changes before they happen. This guide walks you through setting up approval policies, configuring the Change Advisory Board workflow, and building the emergency fast-track path that keeps your environment secure without slowing down critical fixes.
Why manual change approvals break down
Without structured approval groups, change requests either sit in limbo waiting for someone to notice them, or they get rubber-stamped by whoever happens to be online. Change managers end up manually routing requests through email or Slack, which means no audit trail and changes that slip through without proper review. When something breaks in production, you can't trace back to see who approved what, or worse — you discover changes went live with no approval at all. The teams managing production environments — infrastructure, security, and application owners — need predictable approval workflows that don't rely on someone remembering to check their queue.
How change approval groups work together
ServiceNow routes change requests through approval groups based on change models and workflow policies. The change model defines which approval groups are required for different types of changes — standard changes might need just the technical owner, while high-risk changes require CAB approval plus security review. The Change Advisory Board workbench gives approvers a single view to review multiple requests in bulk. Emergency changes bypass the normal approval chain and use a streamlined path that requires change_manager role approval after implementation. Each approval group can have multiple members, and you control whether you need unanimous approval or just one person from the group.
Building production-quality approval workflows
Once basic approvals work, you'll want to add risk-based routing that automatically assigns different approval paths based on the change's impact and configuration items affected. Set up approval delegation so groups don't get blocked when key approvers are unavailable. Configure approval reminders and escalation policies to prevent changes from stalling. For mature change management, integrate with external tools like monitoring systems to automatically populate risk assessments, and use approval analytics to identify bottlenecks in your process.
Before you start
- •change_manager role or admin role
- •Groups created for approval teams (e.g., CAB, Security, Infrastructure)
- •Change models defined for different change types
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Configure approval groups on change models
Navigate to Change > Administration > Change Models and open your target change model. In the Approval Groups related list, click New to add approval groups. Set the Group field to your approval team (e.g., CAB, Security Review), set Order to control the sequence (100, 200, 300), and leave Type as 'Serial' unless you need parallel approvals. The Order determines when each group gets the approval request — lower numbers go first.
Use increments of 100 for ordering so you can insert new approval groups between existing ones later.
Set up the CAB approval workflow
Go to Change > Change Advisory Board > CAB Workbench. This gives CAB members a consolidated view of all changes requiring their approval. To configure which changes appear here, navigate to Change > Administration > Change Workflow and modify the approval activities. The 'CAB Approval' activity should have a condition that matches your high-risk or normal change models. Set the Assignment to your CAB group and configure whether you need unanimous approval or just one approver in the Activity Properties.
Set CAB approval to 'Anyone' in the group rather than 'Everyone' — unanimous approval creates bottlenecks when CAB members are unavailable.
Configure emergency change approval paths
Navigate to Change > Administration > Change Workflow and locate the Emergency change workflow. Emergency changes should bypass normal approval groups and use post-implementation approval instead. Configure the emergency workflow to require change_manager role approval after the change is implemented. Set conditions on approval activities to skip CAB and other groups when change.type equals 'Emergency'. The emergency path should go directly from 'Scheduled' to 'Implement' state, with approval required before closing.
Emergency changes still need approval — just after implementation instead of before, so you can track who authorized the emergency bypass.
Set approval policies in workflow activities
In Change > Administration > Change Workflow, open each approval activity and configure the Assignment and Conditions tabs. Set Assignment to the appropriate approval group, configure the timeout (e.g., 5 days for normal changes, 1 day for urgent), and set the escalation action if approval times out. In Conditions, specify when this approval is required — typically based on change.type, risk level, or affected CIs. Check 'Required' unless the approval is optional.
Always set approval timeouts with escalation actions — changes shouldn't sit indefinitely waiting for absent approvers.
Configure change manager approval authority
Navigate to User Administration > Roles and verify users with change_manager role. These users can approve changes even if they're not in the assigned approval group — this provides an override path for urgent situations. In Change > Administration > Properties, check that 'glide.change.allow_change_manager_to_approve_changes' is set to true. Change managers can approve from the change form directly or use the Change > My Approvals module to see all pending approvals.
Limit the change_manager role to senior staff — it bypasses normal approval group restrictions and should be used sparingly.
Test approval routing with different scenarios
Create test change requests for each change model to verify approval routing works correctly. Submit a normal change and confirm it routes to CAB first, then to technical approval groups in the right sequence. Test an emergency change to verify it skips normal approval groups and allows post-implementation approval. Check that change managers can approve changes outside their normal groups, and verify that approval group members see changes in their queue through Change > My Approvals.
Test with users who only have approval rights, not admin access — they'll hit permission issues that admins won't see.
Best practices
Always define approval timeouts with escalation actions — changes that sit in pending approval indefinitely defeat the purpose of change control.
Use sequential approval ordering (100, 200, 300) rather than parallel approvals unless you specifically need multiple groups reviewing simultaneously — parallel approvals often cause confusion about who's responsible.
Configure approval delegation in each approval group so the process doesn't stop when key approvers are on vacation or unavailable.
Keep emergency change approval simple — the more complex the emergency process, the more likely people will misuse normal changes to avoid it.
Set up approval group notifications to go to the group email or Slack channel, not just individual members — this ensures someone sees the request even if individuals miss it.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue