Workflow Properties in Jira: Restricting Status Transitions to Specific Groups

[#1]

Disclaimer: This is a recurring question in the Community — variations of “how do I lock this transition/status to a specific group?” come up regularly. 

Two tools people often confuse

In the new Jira workflow editor there are two different mechanisms for controlling who can do what:

Tool	Current name	Scope	Where to configure
Restrict transition (formerly Condition)	Workflow Rule	A single transition (one arrow)	Click the transition → side panel → Rules → Add rule → Restrict transition
Property jira.permission.*	Workflow Property	An entire status (all outgoing transitions from it)	Click the status (or transition) → side panel → Properties → Add property

Both are configured through the same side panel, but they operate at different levels. “Restrict transition” rules are the standard tool for “only group X may run this one transition.” Properties are meant for cases that go beyond the permission scheme — as Atlassian's own lesson puts it:

“It's best to manage permissions exclusively in your permission scheme. However, you may have specific use cases worth the administrative burden.”

Property key format

jira.permission.[subtasks.]{permission}.{user}[.suffix]

• {permission}: transition, edit, comment, attach, delete, assign, resolve, close, work, …
• {user}: group, projectrole, user, reporter, assignee, applicationRole, groupCF, userCF,
• [.suffix]: optional number, used when you need to add the same property more than once (e.g. multiple groups)

Worked example: only "qa-team" can transition out of "In Review"

Goal: while an item sits in "In Review", only the group qa-team should be able to run any outgoing transition at all.

1. Get the group ID

The value must be the group ID, not the group name:

• Jira admin → User management → Groups → open the group (ID is in the URL), or
• REST: GET /rest/api/3/group?groupname=qa-team

2. Set the property on the status

1. New workflow editor → click status "In Review".
2. Side panel → Properties → Add property → Add new property.
3. Enter:

Key	Value
jira.permission.transition.group	<group ID of qa-team>

 

4. Save and publish the workflow.

Result: as long as an issue is in “In Review,” only qa-team can transition it — regardless of how many outgoing arrows that status has.

What if only ONE specific transition needs locking?

Then the property is the wrong tool, since it acts status-wide. Use a Restrict transition rule directly on the arrow instead:

5. Click the transition you want to lock.
6. Side panel → Rules → Add rule (+) → Restrict transition.
7. Pick the "User is in group" rule, assign the group, save.

Summary

Question	Answer
Restrict only one transition to a group	Restrict transition rule on that transition
Restrict all transitions out of a status to a group	Property jira.permission.transition.group = group ID, on the status
Need both	Combine them — property as the “safety net,” restrict-transition rule for fine-grained control of individual arrows

The properties don't replace the permission scheme — i use it for edge cases.

Atlassian's own guidance is

permissions in the permission scheme first

and then ,when needed, use workflow properties. 

I hope it helps someone in the future. 

Sources

• Atlassian Support – Use workflow properties
• Atlassian Learning – Create complex workflows in Jira (Use properties to add detailed behaviors to your workflows)

Related discussions in the Community

• Give transition permission to only one specific group
• How to restrict a group or user from performing a particular transition
• Solved: Workflow Properties to Limit Delete, Cloning, and Editing

[Welington]

Hey my friend! Excellent article!

You touched on one of the points that generates the most confusion in Jira administration. Your table perfectly summarized the golden rule: the transition rule acts on the arrow, while the property acts on the entire status.

To complement this great explanation, I'll add a few points:

The Group ID Challenge: Great tip on using the groupId in Cloud instead of the name. Relying on plain text names nowadays is asking to break the configuration. Fetching the ID via URL or REST API is the definitive path.

The Troubleshooting Trap: As you well cited from Atlassian, the Permission Scheme has to be Plan A. Properties act "silently" and the Permission Helper doesn't track them, which drives people crazy trying to understand why a button disappeared. It really needs to be used sparingly.

Subtask Applications: The subtasks. prefix you included (jira.permission.subtasks.*) is a lifesaver! It's the best way to freeze edits and transitions in subtasks when the parent issue enters a restricted status (like "In Approval" or "Closed").

Surgical and straight-to-the-point content. It will definitely save the community hours of research and frustrated testing. Kudos for sharing the knowledge!

[Maria Reisinger]

Great thread! Reading this from a compliance angle: the "Permission Helper doesn't see properties" point stands out to me. It means access restrictions can exist that no standard tool surfaces. For regulated teams that's an audit question waiting to happen: "who could move issues out of 'In Approval', and since when?" Curious how others document workflow properties for audits. Is anyone tracking configuration changes at this level?