I’m looking to implement a workflow in Jira Cloud where each user is only allowed to have one issue in the “In Progress” status at any given time. If a user tries to move a second issue to “In Progress” while they already have one, the transition should be blocked. Key Points: * I will be the sole person configuring the workflows and permissions. * Team members will only be moving tasks through the statuses and won’t be configuring anything themselves. * I prefer to achieve this using Jira’s native capabilities (workflow conditions, validators, and automation) if possible, and only consider paid plugins if absolutely necessary. * Example: * Ram → can have only 1 issue in In Progress * Vimal → can have only 1 issue in In Progress * Multiple users can have issues in In Progress, but only one per individual. Questions: * Can this restriction be implemented using Jira Cloud’s native features? * Are there any limitations in Jira Cloud that would prevent achieving this natively? * If I need to get a paid version of Jira, which plan should I choose? * Is it enough for only me to be on that plan, or do all team members also need to be on the same paid plan? Thank you for your help!

Hello @Aldrine Abisheck Please post * new screen images of your rule * the details from the rule execution audit log for an execution of the rule where you did not get the results you expected * a description of the results you expected versus the results that you got.

Dear @Trudy P Claspill {{lookupIssues.size|0}} is greater than 0 solution haven't worked as expected.

With regard to your automation rule not working. 1. Your first condition will never pass. It is executing the JQL you have provided and checking to see if the trigger issue is within the result set. Since your JQL includes "key != {{issue.key}}" your JQL will never include the trigger issue and the condition will never pass. I think what you were trying to do there is get a list of all issues assigned to the current user, which are also In Progress, while excluding the issue that was just transitioned. For that you need to use a Lookup Work Items action. Let us start with the assumption that this rule is explicitly scoped to a single project. In that case your JQL would be correct for use in the Lookup Work Items action. 2. In this step I believe you are trying to determine if any issues were returned by the JQL. Evaluation of the {{lookupIssues}} smart value works only when it follows the use of a Lookup Work Items action. Changing step 1 to a Lookup Work Items action will enable step 2 to be executed. If the Lookup Work Items action finds no issues the the {{lookupIssues}} smart value has not definition (is null). Modify the comparison as follows to compensate for this case. {{lookupIssues.size|0}} is greater than 0 The |0 instructs Jira to use the value 0 on the left side of the comparison when {{lookupIssues.size}} is null. 3. With step 3 which items do you intend to move to the Hold status? As the rule is currently constructed, the issue that triggered the rule is the one that will be moved to the Hold status. If you want to let the current issue remain In Progress and move the items found by the Lookup to the Hold status that will require different steps. ------ Regarding your statement #3 3. If an Item has no assignee, that item should not be able to move to In Progress. Only an item with an Assignee can be moved to In Progress. That is something you can do by adding a Validator to the workflow to require the Assignee field to be set. ----- ----- With regard to making this a Global rule that would be applied to all projects, changes would be needed. The JQL statement would need to be changed to add a criteria to find issue based on the Project containing the issue that triggered the rule. If you use Team Managed projects, the Status values in them are considered unique values even when the text name is identical. If you have multiple Team Managed projects using the Hold status, that status is actually unique per Team Managed project and also different than the "Hold" status in a Company Managed project. That can cause your rule to fail. If you want the rule to apply globally then you should use only Company Managed projects, as those share globally defined Status values. ------ As I mentioned in earlier replies, there are limitations on the number of rule executions that are allowed per month depending on your subscription plan. Applying the above Automation along with any other Automations you may want to set up could easily cause you to exceed that limit. At that point none of your Automation rules would execute for the remainder of the month. Because of that you may want to consider instead implementing a solution that uses a marketplace app to enable you to customize the workflow. If you maintain 10 or fewer users of your environment and a Free subscription, some of those apps also support free use in such a plan.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How can I enforce a per-user limit of having only one issue in the “In Progress” status at a time?

Aldrine Abisheck

I’m looking to implement a workflow in Jira Cloud where each user is only allowed to have one issue in the “In Progress” status at any given time. If a user tries to move a second issue to “In Progress” while they already have one, the transition should be blocked.

Key Points:

I will be the sole person configuring the workflows and permissions.
Team members will only be moving tasks through the statuses and won’t be configuring anything themselves.
I prefer to achieve this using Jira’s native capabilities (workflow conditions, validators, and automation) if possible, and only consider paid plugins if absolutely necessary.
Example:
- Ram → can have only 1 issue in In Progress
- Vimal → can have only 1 issue in In Progress
- Multiple users can have issues in In Progress, but only one per individual.

Questions:

Can this restriction be implemented using Jira Cloud’s native features?
Are there any limitations in Jira Cloud that would prevent achieving this natively?
If I need to get a paid version of Jira, which plan should I choose?
Is it enough for only me to be on that plan, or do all team members also need to be on the same paid plan?

Thank you for your help!

Accepted answers

All comments

Trudy P Claspill

Hello @Aldrine Abisheck

Welcome to the Atlassian community.

This appears to be an expansion on your newer post:

https://community.atlassian.com/forums/Jira-questions/How-can-I-enforce-a-per-user-limit-of-having-only-one-issue-in/qaq-p/3185335

In the future just add more details to your original post rather than start a new one.

I will have some additional questions about your scenario that I will post separately.

Aldrine Abisheck

Ok. If you need any clarification please ask

Trudy P Claspill

Here are my initial questions about your scenario.

1. How do you determine that a user already has an item "In Progress"? Do you mean that a person designated as an Assignee for an item can have only one "In Progress"?

2. The person assigned to an item may not be the same person moving the item to In Progress. Do you want the item to be automatically assigned to the person who is moving it?

3. What should happen if an item has no Assignee when it is moved to In Progress?

4. Will users have items in more than one Space? If users have items in more than one space does this limitation apply to all items in all Spaces, or to items within a single Space?

5. How do you want to "prevent" the action?
With a Workflow Condition, the transition is hidden from the user.
With a Workflow Validator the user may start the transition and then will be presented with a message that the transition cannot be completed.
With an Automation Rule, the rule is triggered only after the transition completes, so it does not "prevent" the transition but may be used to revert the item to its previous status.

Regarding your questions:

1. Native workflow Conditions and Validators are not sufficient by themselves to implement your requirement. As I stated in #4 above, an Automation rule might work but would revert rather than prevent the transition.

3. If you are using a Free version there are a variety of limitation. In a Free version the number of Automation Rule executions is limited to 100 per month. If this is something that must be implemented with Automation, and there are a lot of items being handled, you could potentially hit that limit and the Automation rule would no longer be effective for the remainder of the month. If you want to use Automation Rules for other tasks that would also contribute to the number of Automation Rule executions per montn.

Free plans are also limited to no more than 10 users, and each user you want to let use the Jira application would count against those 10. If you have more than 10 people working on the items, you will have to use a paid subscription plan.

You can find more information about the differences in features available between the Free, Standard, and Premium plan on the pricing page.

https://www.atlassian.com/software/jira/pricing

4. A subscription plan applies to a product, not to individual users. You would get a Free or paid subscription for Jira, and then grant users access to it. Each user would consume a license. As I said above the Free plan is limited to 10 users. If you need to have more than 10 people working on the items, you will need to get at least the Standard plan.

Bill Sheboy

Hi @Aldrine Abisheck

Trying to solve work in progress (WIP) limit concerns in an automated manner with tools may lead to unintended consequences. Two such consequences could be:

Team members may stop updating work items in Jira and do the work anyway. Thus, work progress and WIP become hidden, and as this behavior becomes the new "normal", the tool is less helpful to the team and leaders.
When there are valid cases to exceed WIP limits, such as an expedited work item, the tool prevents people from doing so. This can lead to confusion of how to handle the more urgent expedited items.

Please consider pausing to discuss with the team their working agreement practices, including WIP limits, to uncover why people may exceed such limits. That root cause analysis may identify a better solution and eliminate the need to add such features to the tool.

Kind regards,
Bill

Aldrine Abisheck

Hi @Bill Sheboy

We have decided to introduce an additional status called HOLD, positioned alongside IN PROGRESS. Whenever a high‑priority item or urgent bug fix needs immediate attention, the task currently in progress will be moved to HOLD before the new task is taken up.

This update is intended to help us capture the accurate development time spent on each task. When a task is moved to HOLD, the time spent in that status should be excluded from the total development time calculation.

Please let us know if you need any further clarification.

Aldrine Abisheck

Hi @Trudy P Claspill
1. A person designated as an Assignee for an item can have only one "In Progress"

2. In our organisation, a person assigned to an item should be the same person moving the item to In Progress.

3. If an Item has no assignee, that item should not be able to move to In Progress. Only an item with an Assignee can be moved to In Progress.

4. Currently there is one Space. But there will be more than one in future. For Users the limitations should apply to items within a single Space.

5. Similar to what you said, I created a global automation rule 'Prevent users from having multiple In‑Progress tasks' . But it is not working.

Prevent Multiple Work To In Progress Transition.png Audit log.png

A suggestion provided by ChatGPT indicates that achieving this functionality may require the use of a synchronous workflow validator, as this is the only method that can block a transition immediately—whether triggered by the UI, API, board drag‑and‑drop, or bulk operations. It was also noted that Jira Cloud’s native workflow validators do not support cross‑issue JQL checks, meaning this capability generally depends on marketplace apps such as JMWE, ScriptRunner, or Power Scripts.

We also want to understand whether any of these options would even be feasible within a Team‑Managed project, since the configuration capabilities there are much more limited. From what we observe, it might be more practical in the long run to start with a Company‑Managed project in order to avoid major constraints later.

However, Jira’s current onboarding flow seems to strongly guide us toward setting up a Team‑Managed project, and we’re looking for a way to avoid that or override it so we can directly proceed with a Company‑Managed configuration. Any guidance or recommended approach on how to achieve this would be helpful.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud