Study guide
6.5 Team-Managed Workflows, Statuses & Workflow Rules
Atlassian Certified Professional - Jira Administration for Cloud ACP-120
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam Overview, Blueprint & Jira Cloud Fundamentals
1.1 ACP-120 Exam Structure, Blueprint & Testing Strategy 1.2 Jira Cloud Architecture, Products & Admin Hierarchy
2 Chapter 2: Organizations, Managed Accounts & Global Access
2.1 Atlassian Organizations, Domain Verification & Managed Accounts 2.2 Atlassian Guard, SAML SSO, SCIM & Authentication Policies 2.3 Site Access, Product Access Tiers & Global Permissions 2.4 User Directory Architecture: Groups vs. Project Roles
3 Chapter 3: Project Permissions & Issue-Level Security Schemes
3.1 Permission Scheme Mechanics & Critical Project Permissions 3.2 Permission Troubleshooting, Additive Permissions & Permission Helper 3.3 Issue Security Schemes, Security Levels & Access Containment
4 Chapter 4: Project Configuration, Types, Versions & Boards
4.1 Company-Managed vs. Team-Managed Project Architecture 4.2 Project Templates, Project Keys & Project Categories 4.3 Project Components, Component Leads & Default Assignees 4.4 Versions, Fix Versions, Release Lifecycles & Project Archiving 4.5 Scrum and Kanban Board Configuration, Board Filters & Columns
5 Chapter 5: Issue Types, Custom Fields, Screens & Schemes
5.1 Standard vs. Sub-task Issue Types & Issue Type Schemes 5.2 Custom Field Types, Global vs. Project Contexts & Options 5.3 Field Configurations, Renderers, Hiding & Required Fields 5.4 Screens, Screen Schemes & Issue Type Screen Schemes
6 Chapter 6: Workflows — Company-Managed and Team-Managed
6.1 Statuses, Status Categories, Direct & All-to-One Global Transitions 6.2 Transition Rules: Conditions vs. Validators 6.3 Post Functions, Execution Order & Resolution Management 6.4 Workflow Schemes, Editing Active Workflows & Status Migration 6.5 Team-Managed Workflows, Statuses & Workflow Rules
7 Chapter 7: Jira Cloud Automation
7.1 Automation Engine, Rule Architecture & Event Triggers 7.2 Automation Conditions, Smart Values & String/Date Expressions 7.3 Branch Rules, Related Issues, Sub-tasks & Parent Epics 7.4 Rule Scopes, Automation Usage, Audit Logs & Error Handling
8 Chapter 8: Notifications, Events, Personal Settings & Mail Handlers
8.1 Jira Events, System Events & Notification Schemes 8.2 Notification Recipients, Custom User Fields & Deduplication 8.3 Team-Managed Notifications, Personal Settings & Troubleshooting Missing Email 8.4 Mail Handlers: Creating Issues and Comments from Email
9 Chapter 9: JQL, Filters, Dashboards & Bulk Operations
9.1 JQL Fundamentals, Clauses, Operators & History (WAS / CHANGED) 9.2 Advanced JQL Functions & Dynamic Date Searches 9.3 Filter Permissions, Shared Filters & Filter Subscriptions 9.4 Dashboard Layouts, the Default Dashboard, Sharing & Essential Gadgets 9.5 Bulk Operations: Edit, Move, Transition, Delete & Watch
10 Chapter 10: System Administration
10.1 Global UI Features: User Defaults, Look and Feel, Announcement Banner & Default Dashboard 10.2 Statuses, Resolutions, Priorities & Sub-tasks: Global Configuration 10.3 Global Settings: Time Tracking, Issue Linking, Attachments & Application Links 10.4 System Backup, Restore & Data Import
6.5 Team-Managed Workflows, Statuses & Workflow Rules
Key Takeaways Explain This Topic AI
In team-managed projects, the project admin edits each issue type's workflow from Project settings > Issue types and confirms which issue types the updated workflow applies to.
New team-managed statuses get an 'Any status' transition by default; limits are 100 statuses per project and 50 per workflow.
Each transition can hold up to 10 rules: assign, restrict by field value, restrict by previous status, restrict who can move, validate a permission, copy a field, or update a field.
Team-managed statuses and rules affect only that project, while company-managed workflows are global and shared through workflow schemes.
Deleting a transition deletes its rules, and deleting a role breaks any rule that references it.
Last updated: September 2026
6.5 Team-Managed Workflows, Statuses & Workflow Rules
Blueprint objective 4.2 covers team-managed workflows : configuring workflows for issue types, creating and configuring statuses, and configuring workflow rules. Team-managed projects don't use workflow schemes or the company-managed rule catalogue. The project admin edits everything inside the project, and changes affect that project only.
Where Team-Managed Workflows Live
In a team-managed project, each issue type has a workflow, and you edit it from the issue type:
Open Project settings > Issue types (Work types) and select the issue type.
Select Edit workflow .
Add or change statuses, transitions, and rules in the workflow editor.
Select Update workflow , then confirm which issue types the workflow applies to.
Team-managed projects can have several workflows , for example a lightweight flow for tasks and a review-heavy flow for bugs. Because you confirm the issue types on save, you control whether a change applies to one issue type or to all that share the workflow.
Topic Company-Managed Team-Managed
Who edits Jira admin (or a holder of Edit workflows , if the workflow isn't shared) Project admin of that project
How a workflow reaches issue types Workflow scheme maps issue types to workflows Chosen per issue type when you update the workflow
Statuses Global objects shared across the site Belong to the project
Rule catalogue Full restrict / validate / action rule set, properties, and events A smaller set of team-managed rules
- Scope of a change Every project using the workflow Only this project
- Statuses in Team-Managed Workflows
Creating a status: add it in the workflow editor and choose its category (To Do, In Progress, or Done).
Default transitions: a new status automatically allows issues in any other status to move into it. The Any status label on the diagram represents this global transition.
Limits: Atlassian allows up to 100 statuses across all of a project's workflows and up to 50 statuses in any one workflow .
Renaming a status affects only that project. Company-managed projects are untouched, which is very different from renaming a global company-managed status (Chapter 10).
Boards follow the workflow. Team-managed boards are tied to the project's statuses, so adding, renaming, or removing statuses shows up as board columns. Map every "finished" status to the rightmost column so sprints count them as complete.
Editing and Deleting Transitions
You can replace an Any status transition with more restrictive transitions (for example, only In Review can move to Done ). Atlassian warns that tightening transitions can cause errors when people drag cards across the board, because some moves are no longer allowed. Deleting a transition also deletes the rules attached to it.
Team-Managed Workflow Rules
Rules are added to a transition, and each transition can hold up to 10 rules . The available rules are:
Rule What It Does Example
Assign a work item Sets the assignee when the transition runs: the reporter, the current user, no one (unassigned), or a specific person Moving to In Review assigns the issue to the QA lead
Restrict to when a work item is a specific value Allows the transition only if a field compares as configured (equals, contains, greater than, is before, and so on) Only allow Approve when Budget is 5,000 or less
Restrict to when a work item has been through a status Allows the transition only if the issue has (or, with Reverse this rule , has not) been through a status. Options: include the current status, only consider the most recent status, ignore looped transitions Only allow Done if the issue has been through In Review
Restrict who can move a work item Limits the transition to the assignee, reporter, a chosen user, a role, a group, or people with a specific permission Only the Quality assurance role can move issues out of In Review
Validate that people have a specific permission Checks a Jira permission (for example, Close Issues) before the transition runs Only people with Close Issues can move work to Done
Copy the value of one field to another Copies a field within the issue, or from the parent issue to the child. Depending on field type, the copy appends or replaces Copy the epic's Target quarter down to each story
Update a work item field Sets text, number, label, date, or time fields. Text is appended ; date and time fields are set to the moment of the transition Stamp Handed to QA with the transition date
Two behaviors are easy to miss:
Rules that don't apply are skipped, not failed. For example, a copy rule skips issues that lack either field or have no parent.
Removing a role breaks the rules that reference it. If a Restrict who can move rule points to a deleted role, the team may be unable to move issues until the rule is updated.
Worked Scenario
A team-managed software project wants: (1) only QA engineers can mark work done, (2) nothing reaches Done without passing In Review , and (3) the date of the QA hand-off recorded automatically.
Create a custom project role QA engineer (duplicate Member and adjust permissions) and add the testers.
On the transition into Done , add Restrict who can move a work item (role: QA engineer) and Restrict to when a work item has been through a status ( In Review , with Include the work item's current status and Only consider the most recent status selected).
On the transition into In Review , add Update a work item field to set the Handed to QA date.
Update the workflow and confirm the issue types it applies to.
No Jira admin, workflow scheme, or permission scheme is involved. That's the core difference the exam tests.