Announcing Priority Schemes in Jira

[#1]

Hi everyone,

We're thrilled to announce the release of Priority schemes for Jira Cloud, letting you customize priorities for your projects. This much-awaited feature has gathered significant interest, as evidenced by the numerous signups for our Early Access program. Exiting the Beta phase, we're now progressively rolling out priority schemes across all sites in the upcoming weeks.

What will be available?

By default, all the priorities you have today will be in a default priority scheme for all existing projects, and you’ll be able to continue using Jira as-is.

With the new functionality, you can:

• Add or remove priorities in the default priority scheme.

• Create your own custom priority schemes for specific projects.

• Edit or delete priority schemes.

• Manage priority schemes in Jira settings.

You can configure Priority Schemes on the Priority Schemes page via  > Issues > Priority Schemes:

Differences to Jira Server & Data Center

If you’ve recently migrated or a planning a migration from Jira Server or Data Center, there are some differences worth noting.

• Delete a priority:

  • You can't delete a priority if it’s associated with any priority scheme. You must first remove the priority from the priority scheme(s) and then delete the priority.

  • You will be able to map deleted priorities to a new priority.

• Delete a priority scheme:

  • You can't delete a priority scheme if it’s associated with any project. You must first remove the project(s) from the priority scheme and then delete the scheme.

  • If there are archived project(s), they will be moved to the default priority scheme.

• The order of priorities:

  • In the Priorities page ( > Issues > Priority), the order that you see is the order in which the priorities are shown in the priority scheme, and in the dropdown menu when a user creates or edits an issue.

  • You can change this order only from the Priorities page

• Modify a priority scheme:

  • If you’re updating a priority scheme with projects and priorities, and some issues use priorities that are no longer available in the projects, you will be able to map removed priorities to a new value.

• Update an issue’s priority with workflow rules:

  • If you have a workflow rule for a project to update an issue’s priority to a priority that is unavailable in the project’s priority scheme, then the priority field will not be updated when the rule is triggered.

Frequently Asked Questions

• Will the feature be only available for Jira Software projects?

  • You’ll be able to customise priorities for Jira and Jira Service Management projects. Jira Product Discovery projects do not make use of the Priorities field at this stage.

• Will I be able to set different priority schemes for different Issue Types in a project?

  • Similar to Jira Server, you cannot set different Priorities for different Issue Types at this stage.

• I’m migrating from Server/Data Center, will my Priority Schemes be carried across?

  • We support migration to Jira Cloud with Jira Cloud Migration Assistant (JCMA). If you're migrating with JCMA, you can use your priority schemes from Server/Data Center in Cloud.

• Are all the priorities included in the default priority scheme?

  • Yes. When you add a new priority, it will automatically be associated with the default priority scheme. You can edit the default priority scheme to remove priorities.

• Can I associate priority schemes with both company-managed and team-managed projects?

  • Yes, Jira admins can associate both company-managed and team-managed projects with priority schemes. 

  • For team-managed projects, the project admin can set the default priority per issue type in project settings.

• Can trashed and archived projects be associated with priority schemes?

  • You wont be able to see trashed or archived projects on the Priority Schemes page (> Issues > Priority Schemes). This means you can’t see which trashed or archived projects are associated with a priority scheme and you can’t remove or add a trashed or archived project to a priority scheme.

  • Projects that are already trashed or archived will be associated with the default priority scheme.

• Are there any limits imposed?

  • Yes, we have the following limits per instance:

    • 300 priorities

    • 300 priority schemes

    • 300 priorities in a priority scheme

[Trudy Claspill]

Hello @Carol Low 

I have questions related to this:

• I’m migrating from Server/Data Center, will my Priority Schemes be carried across?

  • We support migration to Jira Cloud with Jira Cloud Migration Assistant (JCMA). If you're migrating with JCMA and the EAP is enabled for your instance, you can use your priority schemes from Server/Data Center in Cloud.

1. In which version of JCMA is migration of Priority Schemes supported? The What Gets Migrated with JCMA document that is available today says that migration of Priority Schemes is not supported.
2. How do we get the EAP enabled for our instance?
3. I am currently doing test migrations to sandboxes on a Premium Trial instance. I will destroy and deploy new sandboxes repeatedly to retest the migration to a clean cloud instance. Do I have to ask for the EAP to be enabled for each new sandbox?

[Vedant Kulkarni_Trundl]

Finally!!

Waiting to roll it out on my customer sites.

[Trudy Claspill]

Hello @Carol Low 

I have additional questions, because of these statements:

• Can trashed and archived projects be associated with priority schemes?

  • You wont be able to see trashed or archived projects on the Priority Schemes page (> Issues > Priority Schemes). This means you can’t see which trashed or archived projects are associated with a priority scheme and you can’t remove or add a trashed or archived project to a priority scheme.

  • Projects that are already trashed or archived will be associated with the default priority scheme.

If we are migrating an Archived project from DC to Cloud (using JCMA), will the migration retain the project's association to its priority scheme? 

If, in Cloud, we have a project associated to a priority scheme and we Archive it, does it retain its association to the priority scheme such that if it is restored it is still associated to the priority scheme?

[Gal Fatal]

Good news.

[Haddon Fisher]

Hey @Carol Low so excited for this! Two questions for you:

1. Has any thought been given to fixing the behavior around adding all priorities to the default scheme? I think we talked about this during the EAP but I can't find that post so just in case it's gone:

• All projects are being moved to the 'default' priority scheme
• Adding a new priority will result in that priority being automatically added to that scheme
• Team-managed projects without a default priority explicitly set for each issuetype will use what it believes is the 'middle' priority for the default. These must be set manually for each issuetype in each TMP.
• There is no discernable value in adding all new priorities to the default scheme.

This results in changes to the default priority across all TMP's as soon as you add a new status. 

2. When will we see "Priorities" in the project settings? There's an expectation that when looking at project settings, you would see a link to the priority scheme being used and an option to change it (similar to how workflows, screens, and other project-level configs work). These UX patterns should be maintained to provide consistency.

[Kristján Geir Mathiesen]

Well done!

[Ulf Johansson]

Hi @Carol Low 
Good news!
Do you have a date when you are rolling out this?
We are very eager to have this feature due to going live with a new ITSM-projecct.

/Regards Ulf

[Lee Theriault]

Hello, would it be possible to be included in this rollout? If not how much longer until rollout is complete for all jira cloud users? Thanks much

[Carol Low]

Hi Everyone!

The feature is now live for everyone except for instances configured with JSM Chat - there is an outstanding issue which causes the wrong priorities to come up. There are some dependencies on related rollouts so there will be a delay for these customers until early-mid June. 

If you are using JSM Chat and would still like it enabled with the known issue, please contact me at clow@atlassian.com (please note since it's my personal email there might be delays in responding)

Addressing some questions:

@Trudy Claspill 

• Migration of Priority Schemes by JCMA is supported concurrently with the Priority Schemes rollout. The document will be updated shortly after rollout is complete.
• Archived projects should retain their values through Migration
• Archived projects in Cloud will maintain their association to the schemes, unless the scheme is deleted, in which case they will be remapped to the default priority scheme

@Haddon Fisher 

• We will continue to monitor and address feedback around the default behaviour of the default scheme - thanks for continuing to provide them!
• We are looking into improvements of how settings are laid out today and will address as part of it - which may mean it's not something we add immediately, but I'll keep you posted

[Dirk Ronsmans]

Hi @Carol Low ,

Seems it's not a 100% out there yet :)

When I use the keyboard shortcut  (gg) I get an option for priority schemes but it leads to a 404 dead link page :o

Also in the settings menu itself there is no entry yet.

Shall I send you an email with our instance to validate or am I just jumping the gun here ? :)

(can you see how excited we are for this feature ;-))

[Carol Low]

@Dirk Ronsmans 

I'm loving the enthusiasm! feel free to send it to me and I will have a look.

[Dirk Ronsmans]

Hi @Carol Low ,

Quick follow up question. When a priority scheme is associated with a project we need to map the old existing priorities to it's new equivalent. (makes sense)

However there is no option to enable or disable communication when the change occurs (similar to a bulk change).

Will this trigger the communication on a ticket (issue updated) or is this by default disabled?

[Carol Low]

Hey @Dirk Ronsmans

The changes as part of the mapping process are not communicated via email or in product notifications. Do you see any use cases for which you would want an option to do so?

[Dirk Ronsmans]

@Carol Low , 

No not at all :-) I would even prefer it as is that it doesn't get communicated to not spam users with all the updates.

Although an option to do so would be nice especially if you were to migrate some issues to a higher priority to notify the assignee's of it and avoid accidental SLA breaches. But definetly not a must just a nice to have.

[Monica Brazelton]

This is fantastic, thanks for implementing this Atlassian!!

[Urmo]

Hi

How many character can set as priority level name?

[Michiel Schuijer]

Now, if only this could be implemented for Resolutions as well...

Resolution Schemes per project that allow project admins to select which ones to be available per issue type.

https://jira.atlassian.com/browse/JRACLOUD-80093

[Rick Westbrock]

I too would prefer that new priorities not be automatically added to the Default priority scheme. I am thinking of creating a Standard priority scheme and associating our 200+ projects which currently use the Default scheme to the Standard scheme so that going forward admins can create a new priority scheme when they add a new priority and switch their project to the new scheme.

[Josh McManus]

@Michiel SchuijerI am able to limit Resolutions through workflow transition properties. You can use the property "jira.field.resolution.include" or "jira.field.resolution.exclude" and then list the resolution ID's that you want to operate on for that transition. The great thing about this is you can create special-purpose transitions that filter resolutions specific to the transition. For example, I have a "Resolve not Done" transition that only offers relevant resolutions like "Won't Do" or "Duplicate", as well as a "Resolve as Done" which uses the transition Post-Function to just set the resolution to "Done". It makes resolving issues for users a breeze and ensures consistent and accurate data. And now that Workflow Editing permission has been rolled out for projects, this functionality could be delivered to Project Admins as well.

[Michiel Schuijer]

Hi @Josh McManus

I am aware of that method, have applied it many times, and we have it in use as well in my current company.

However, it is much more a hack than a user (admin) friendly option, I would say. It is more work to apply this method, it is not possible to just select the resolutions and instead requires you to look up the IDs, the setting is hidden in the workflow properties, making it hard to maintain, etc.

Besides this, Workflow Editing permission for Project Admins will probably not solve this, because the workflow edits that will be possible will probably not include status/transition properties and advanced options like post functions.

Even if it will be possible, it would mean this convoluted method would need to be explained to project admins, on how to apply it and it would require a Jira admin to provide them the resolution ID's. Does that really sound like a good idea?

I would rather Atlassian offer easy to understand and use methods for project admins to find tune their projects, so the burden is removed from the Jira admin completely or at least mostly.