Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Loophole found in Simplified workflow, allows workflow state creations for Project Admins


I was recently browsing through an article which talks about the difference between Simplified Workflow and Jira Workflow. Below is the article link

To test the Simplified workflow, I then created a Scrum Software Development project (Did not use the Create with Shared Configuration while creating project) which also created a board and workflow by default.

Loophole :
The project creation will also create Simplified Workflow and board. If you navigate to the project and then go to the 'Board' and select 'Configure' and navigate to 'Columns' section, on to the right side of the screen, you will see 'Add status' button.
Please note that a user with a 'project administrator' role will be able to add and existing workflow OR 'Create a new workflow' from this screen.
This workflow state created from this screen is a Global item, meaning any workflow (be it a Simplified Workflow or a Jira workflow) can use this state in their workflows.

It would be haphazard if such privileges are given to the Project Admin levels who may start creating workflow states as per their project requirements but that workflow state would be added globally for everyone to use.
As on today, if a company uses both Software Simplified Workflow and a Jira Workflow (maintained by Jira admins), then such companies will have troubles controlling the Workflow State creations.

Just a thought from my side on how this could be resolved. The product development team could think of making a few architectural changes in the way the application holds this data in their database. I mean, they can have separate Pools for Simplified workflows states and Jira workflow states instead of storing/mixing up everything in the same place in DB.
Also, within the Simplified workflow states Pool, there can be project specific Pools which will hold the project specific workflow states.
By this, the workflow states can be specific to only those projects which create them, rather than sharing it globally.

Please share your thoughts and opinions.

1 comment

Ok, this is not a "loophole", it is intended to work this way.

Project admins are supposed to be able to create new status for their simplified workflows, it's one of the main reasons for implementing simplified workflows.

As for the haphazard or global effects, there's something missing here - they can only add (or remove) status from simplified workflows they control.  Changing a simplified workflow only affects that workflow, it does not affect others.  And a simplified workflow is limited to the projects that the admin has access to.  You can't change other workflows, only the simplified ones you own.

There is one problem here you have correctly identified - yes, the list of status is global, so in theory if a simplified workflow uses a status that non-simplified workflows use, they could rename a status.  Note that the status is just a label, it does not change any workflow using it, it is JUST the label.

The Jira admins (of which you only have 3-10, working in a single team, right?) simply don't use shared-workflow built status in the main workflows, keep a lookout for status name changes, and have a duty of education to the project admins "Yes, we will enable simplified workflow for your board across your projects, if you promise not to rename status".

Then again, the system I looked at most recently didn't allow status to be edited in simplified workflow, if the status was used by any other workflow.

Like John M Funk likes this

Hi Nic Brough _Adaptavist_

Thanks for sharing your thoughts and sorry for the delayed response as I was on vacation.

The question still remains and I still believe this is a loophole in the product.

Explanation :
For any user to create new Statuses in Jira, they have to go through the Admin Portal. Meaning, they have to go to
Administration --> Issues --> Under Statuses section, click 'Add Status'
Administration --> Issues --> Under Workflows, from either an existing or a new workflow, you will be able to create new Statuses.

In both the above options, Jira application has been designed in such a way that the Status creations should happen only by the user having Jira Admin rights.

But, with the Simplified project, a user WITHOUT Jira Admin rights, having just project admin rights, will be able to create Statuses which will be Global.

As I mentioned in my earlier comment, this will be a problem if a company uses both Software Simplified Workflow and a Jira Workflow (maintained by Jira admins), then such companies will have troubles controlling the Statuses creations.

Please also note that a Status created by one project's admin is accessible globally by all other projects in that jira instance. Meaning, other project admins from other projects can start using those statuses.
If there is no distinctions between which Statuses are Global items and which Statuses are project specific items, this may mess up the whole setup.

Big companies like ours have thousand projects and if each project starts creating their own Statuses, we will have 1000 statuses to deal with, Not at all the right way.

I strongly feel there has to be a way these project specific workflow statuses are managed within Jira Application.

I'm struggling with your description of this as a "loophole".  To me, a loophole is "a way to get through something that I am normally blocked on doing because I'm not supposed to be able to do it"

Being able to create new status that have no impact on anyone else is not a loophole.  It's there by design.

The whole point of simplified workflows is that people can create their own, and that means they need to be able to create new status as part of it.

If you have a problem with this, then there is a simple answer - you need to control what your projects are doing centrally, so stop simplifying workflows.  Remove existing ones, swapping them to a fixed workflow scheme.  Problem solved.


Log in or Sign up to comment
Community showcase
Published in Jira Software

Upcoming changes to epic fields in company-managed projects

👋 Hi there Jira Community! A few months ago we shared with you plans around renaming epics in your company-managed projects. As part of these changes, we highlighted upcoming changes to epics on...

14,947 views 38 49
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you