Hi everyone,
Back in November 2021 someone here asked how to set up a change approval board with six people, three IT people and three from the business side, and in a follow-up wrote "where is that Change Approval window ... I can't seem to find it". Gaurav's answer there, set the count when you add the approval, still works, but the thread shows how hidden these settings are, so on 17 October 2026 our team built a small CAB on our own Premium test site to see what the current template does. There were two of us in the CAB group, a colleague and me, so each test change was waiting on one of us.
I don't work for Atlassian, and this was one test site with a two-person group, so please treat it as what I saw and check it against your own screens. You'll also need Premium or Enterprise for a new setup, because Atlassian moved change management out of the Standard plan on 16 October 2024.
What the change template already gives you
The approval step is already there. Our space came from the current IT service management template on 29 September and nobody had touched its change workflow. It has one approval, switched on, on the Authorize status. It asks for one approver from each group in the Approver groups field, leaves out the reporter and the assignee, and can also take approvers from the change's Affected services. For that IT plus business board, you'd put both groups in Approver groups and get one yes from each side by default. If you want three from each side, the setting you're after is "Number of approvers" in Add an approval step to a workflow, though we didn't change that number on our site. Your approvers don't need agent licences either, since Atlassian's approvals page says they only have to be customers of that space.
Your older spaces may look different, and I found the docs disagree here. Enforce an approval step for change reviews says the default workflow "doesn't force approvals", while the issue statuses page still names "Awaiting CAB approval" and "Peer review / change manager approval" as defaults. On three older change workflows on the same site, from July, both of those statuses had an approval that was switched off, so check your own workflow before you follow either page.
Leaving out the reporter and the assignee makes a two-person group thin, because whenever one of us raised a change, the other was the one person who could approve it. I don't know of a built-in way to delegate an approval, and JSDCLOUD-7867 is still open for it, so unless someone edits Approver groups to add a stand-in, or an automation rule swaps the approver field, which Jack Yu's sequential approvals guide on this board mentions, a holiday means your change waits. My feeling now is that three people is the smallest CAB that would get you through a normal summer.
Changes that never reach Authorize
The approval path by change type is the part that surprised me the most, and I'd check it on your own site first. Review has eight transitions out of it, including Decline, Fail and a direct Ready for approval, and none has a condition. Normal change sends it to Planning and on to Authorize, but Emergency override jumps to Implementing, Standard change goes to Awaiting implementation and Mark as done goes to Completed, and none of those three touches the approval step or looks at the Change type field. Declined has an open Back to review too, so a change your CAB turned down can come back and leave that way.
So as the template ships, the path is whichever button somebody clicks. Jack Yu's guide from June shows the fix, a condition on each transition keyed on a field value, and I'd expect the same idea to work here with Change type on Emergency override and Standard change. We didn't add those conditions on our site, so I can't say how they behave with the Declined > Back to review loop.
The request form won't help you either. On our "Request a change" form only Summary and Description were required, and Approver groups wasn't on the form at all, so something else has to fill it for you. We used one automation rule that put the CAB group into Approver groups whenever a Normal change was rated High or Critical, and that's how we found the stuck one. A low-risk Normal change, skipped by the rule on purpose, still went into Authorize with an empty Approver groups field, and the panel said one person from each group must approve "but there are no groups". Nobody could approve it, and it could only go Back to planning or be canceled, so it sat. If only some of your changes go to the CAB, give everything else a fallback group, a change managers group for example, so nothing lands in Authorize with nobody to ask.
Freeze windows: where they are and what they block
The change calendar sits under Operations > Change calendar in each space, and only agents can open it, while Views > Calendar is a different screen. Atlassian's What are change windows? page calls them "visual indicators that show when change requests should (or shouldn't) be scheduled", but Jack Yu's announcement from October 2025 says admins "can configure the calendar to automatically block change requests". I think they're both right, because the block is a setting and on our site it was off. It's under Space settings > Operations > Change management > Change windows as "Prevent change creation during freeze windows", and until you tick it, nothing stops a change being planned into your freeze.
With it ticked, we tried five creates through the REST API. A Normal change planned inside a freeze that was already running, a Normal change planned into a freeze set for a few days later, and an Emergency change planned into that same later freeze were all refused with "You can't create a change during an active change window". The message says active even for the freeze that was days away. A fourth, planned outside any window, went through as it should. The fifth had no Planned start or end at all, and it was created while that running freeze was still on. The check reads the planned dates, so if you rely on it, make both planned date fields mandatory on your change request type. Emergency changes get no exception, and when someone asked under that announcement about letting urgent changes bypass a freeze, the answer from Atlassian was "At present it's All / None".
For rolling month-end freezes, Marc's answer in Freeze period for Change Requests back in April 2025 was that "Smart values can't be used in creating a freeze window. There is also no option in the API for this." Nothing I saw in our build changes that, but freezes per service are less clear to me. The window form on our site had fields for an affected service and an Assets object, the ones Create, edit, or delete change windows describes, but we left them empty. The announcement says the block can be enforced "at both the project and service/asset level", and under it Rune Rasmussen found that a window tied through a custom Assets field "will just apply to all objects in our schema", so I'd test it on one of your services before you rely on it.
Finding the changes that skipped your CAB
For your audits, the field you want is Approvals, plural. The JQL functions page writes it that way in all but one example, approval = myApproval(). A strict parse of approval = approved() fails with "Field 'approval' does not exist or you do not have permission to view it.", but the search API hands you back an empty list with no error, as it does for any field name it doesn't recognise, so an export built on the singular looks like nobody approved anything. The parser also rejects declined(), and JSDCLOUD-5420 is still asking for a way to search declined approvals.
The approval functions can't see a change that skipped the approval step, though. In our test an emergency change took Emergency override straight out of Review, and the query that found it read the status history:
project = ABC AND issuetype = "[System] Change"
AND status was not Authorize
AND status was in (Implementing, "Awaiting implementation", Completed, Failed)
It also picks up your real standard changes through the other two exits, which I think you can live with for a weekly look-back. It won't list a declined change sent back to Review, since that one did pass Authorize, so you'd want a second query with status was Declined in place of the second line.
Don't count on the audit log for this either. Jira's own audit log covers "configuration changes that can impact users and spaces", and the organization audit log only stores events if you have Atlassian Guard or an Enterprise plan, and then keeps them for up to 180 days. Jira does record who approved once the step completes, but as Jason D'Cruz from Atlassian explained in 2021, it doesn't record which group they came from when there are several. I'd keep saved filters for your auditor and pull a CSV from them as often as they want one.
Some CAB basics you'd expect are missing too. You can't require a comment on Approve or Decline, and JSDCLOUD-6989 has 738 votes. Validators don't run on approval transitions either, so an approver "can approve or decline the request even if the required field is empty", which a KB article says is expected behaviour, and JSDCLOUD-6988 asks to change that. Any checks you need belong on an earlier transition, before the change reaches Authorize.
We didn't test approval by email or approvers coming from Assets. If you've put conditions on those Review exits, did you key them on Change type, and what happens when a real emergency gets raised as a Normal change by mistake?
