Setting up sequential approvals for change management in Jira Service Management

[#1]

Hello Atlassian Community 👋

If you're a Jira Service Managment project admin trying to configure approval workflows that go beyond the basics — sequential approvals (A → B → C), one-or-more from a group, or all-in-group approvals — this guide walks you through how to do it using workflow statuses, conditional transitions, and approver fields.

The problem

Jira Service Management supports powerful multi-stage conditional approvals, but setting up Change Approval Board (CAB) patterns—like sequential reviews, minimum approver counts, or risk-based approval paths—requires a bit of configuration know-how. This guide walks you through exactly how to set it up so your team can take full advantage of these capabilities.

In this post, we'll help you set up a workflow that supports:

• A lenient path: no approval needed (e.g., staging deployments)
• A strict sequential path: multiple approval stages with different approver groups (e.g., production deployments)

Note: The path is determined by a field value (e.g. Environment).

Prerequisites

Before you start, make sure you have:

• A Jira Service Management project using a change management request type
• Admin access to workflows, workflow schemes, screens, fields, and request forms
• Approver groups created for each approval stage
• A field to determine the approval path (e.g., Environment)

---

Step 1: Create the project and associate a custom workflow

1. Create a project using the IT Service Management template.
2. Go to Settings → Work items → Workflows and create a new workflow for system changes.
3. Go to Workflow schemes and edit the scheme used by your project.
4. Remove the existing workflow association for the System Change request type (if needed).
5. Add your new workflow and associate it with the System Change request type.
6. Publish the workflow scheme and complete any migration steps.

Step 2: Configure workflow statuses and conditional transitions

Add these statuses to your workflow:

• Started
• Approval 1
• Approval 2
• Completed
• Rejected (optional, for tracking declined requests)

Then configure your transitions:

Transition	Purpose
Open → Started	Initial transition into the workflow
Started → Completed	Lenient path (no approval)
Started → Approval 1	Strict path (first approval stage)
Approval 1 → Approval 2	Moves forward after first approval is granted
Approval 2 → Completed	Completes after second approval is granted
Approval 1 → Rejected	First approval declined
Approval 2 → Rejected	Second approval declined

Add conditions on the transitions from Started:

• Lenient: allow Started → Completed when Environment = staging
• Strict: allow Started → Approval 1 when Environment = production

Note: This is an example setup. You can design your own conditional paths with additional statuses, transitions, and approval stages to match your governance requirements.

Step 3: Configure approver fields, screens, and approval steps

Create approver fields

1. Go to Settings → Work items → Fields.
2. Create a multi group picker field called First Approvers.
3. Create a second multi group picker field called Second Approvers.

Use group picker fields when approvals go to groups. Use user picker fields if approvals should go to specific individuals.

Add fields to screens and forms

1. Add Environment, First Approvers, and Second Approvers to the create, view, and edit screens for your change request type.
2. Add the same fields to the request form if users should provide these values at creation time.

Configure approvals on workflow statuses

1. Edit the workflow.
2. On the Approval 1 status, add an approval step using First Approvers as the approver source.
3. Set the approval rule (e.g., at least one approver from the group).
4. Set the approved transition to Approval 2 and the declined transition to Rejected.
5. On Approval 2, add an approval step using Second Approvers.
6. Set the approved transition to Completed and declined to Rejected.
7. Configure whether the reporter can approve their own request.
8. Publish the workflow.

Step 4: Test the lenient path (no approval)

1. Create a change request with Environment = staging.
2. Move the request from Open → Started → Completed.

Note: No approval is required - the request moves straight through.

Step 5: Test the strict sequential approval path

1. Create a change request with Environment = production.
2. Set First Approvers and Second Approvers to the appropriate groups.
3. Move the request from Open → Started → Approval 1.
4. A member of the first approver group approves.
5. The request moves to Approval 2.
6. A member of the second approver group approves.
7. The request moves to Completed.

Note: If an approver declines at either stage, the request moves to Rejected.

💡 Things to keep in mind

• The condition field (Environment) must be available on screens and forms so Jira can evaluate the workflow conditions.
• Approver fields must be on the issue for JSM to resolve who can approve.
• Only eligible approvers from the configured field can approve or decline at each stage.
• Approver-related fields can be added to the create and view screens only if you want the field to not be editable via the UI (i.e., excluded from the edit screen).
• Since approver-related fields are standard Jira fields, they can be transformed via Automation for Jira (A4J) like any other field. This can help with approval delegation if needed.
• You can extend this pattern to three or more approval stages by adding more statuses, transitions, and approver fields.
• Document the expected condition field values so your team knows which path a request will follow.

Questions or feedback?

If you run into issues or have questions about this setup, reach out to us in the comments below. We'd love to hear how you're using sequential approvals in your environment and what other approval patterns you'd like to see covered!