How Do I Change Workflows/Screens/Issue Types (Schemes) for a Project?

[#1]

There are various reasons why we might need to change out schemes for a project. The following information applies to Jira Cloud Company-managed projects (CMP).

The Scenarios

Default Schemes

Perhaps we are using a default scheme and need to have something more tailored for our project. These are probably the simplest scenarios - when the project is using the Default Notification Scheme or Default Permission Scheme that comes with your Jira site.

While they are a good start for most projects, you often need to tweak them for some of your projects. We can’t just update the default scheme with the project specific information. We need to create a new scheme and replace the one that is there. The same might also be true for Field Configuration Scheme.

Shared Configurations

Another common scenario is when we have multiple projects using the same scheme, and one project needs to make a change. If we update the shared scheme, it will change for all projects. So, again, we need to create a new scheme.

Switching Out Schemes

Most of the schemes are switched following the same procedure. The exception would be the Workflow Scheme, which we will discuss last.

To change the schemes, you must be a Jira Administrator.

While on a project, click on Project Settings. You most likely will land on the Project Details page. At this point, you could click on the appropriate related link on the left-hand menu, such as Permissions; however, I like to go directly to the Summary view in the project settings.

The reason I like to start here for almost all of my project configurations is because many schemes are available in one view.

To make a change, simply click on the name of the Scheme. For this first example, we will use the Issue Type Scheme. Clicking on the scheme name will show detailed information about the scheme. Click on the Actions menu on the upper right and select Use a different scheme.

On the following screen, select a new scheme from the dropdown (they should be in alphabetical order) and then click OK.

For the most part, all schemes except the Workflow Scheme will follow this same pattern. You will be done with the switch for most schemes at this point.

Exceptions

If you are on the Free subscription plan for your Jira instance, you will not be able to change the Permission Scheme.

If you change the Issue Type Scheme and the new scheme does not contain issue types that were available in the previous scheme, you will need to migrate the previous issue types to one of the issue types available in the new scheme.

Workflows

To change the Workflow Scheme, click on the name of the workflow as above. Making the change is much more obvious here as you just need to click the Switch Scheme button.

Like the Issue Type Scheme, if your new Workflow Scheme contains workflows that have different Statuses than the previous workflows, the system will walk you through the migration process from the old statuses to the new statues.

The process as a whole is simple and fairly straightforward. Let me know your thoughts in the Comments below.

[Susanna Babayan]

Hey @John Funkthanks for the article !

I have a question about the schemes: generally speaking I've heard it's not a good practice to edit default schemes created by Jira once the project itself is created. Do you share that opinion? And if so, could you please elaborate? I've heard it's good to avoid that but never why...

[John Funk]

Hi @Susanna Babayan  - great question! I edit them to provide the base that I want, especially if the out of the box default scheme from Atlassian is not what I want. For example, I ALWAYS modify the Default  Permission Scheme so that only Jira Admins can Delete Issues. 

After I have the base that I want for all Default schemes, then I always make copies of those schemes to create project specific or additional schemes. 

[Evan Fishman - Rally for Jira]

Thanks for this @John Funk 

[John Funk]

You are welcome @Evan Fishman - Rally for Jira !

[Susanna Babayan]

Thanks @John FunkYour practice makes more sense to me :) 

[MattD]

I always make sure to name new schemes so that the name ends in " scheme". It makes several parts of Jira easier to view

Also, you may want to change schemes first in a test instance. Changing the issue type scheme may prompt you to map old issue types to new issue types, which may well be using different workflows and thus statuses, and then you may need to select different statuses for existing issues.

Understanding how the different Jira schemes are related is a best admin practice in general

[Morgan Watts]

Hello, @John Funk (By the way, “Mr. Funk” has a nice ring to it.)

Do you have any best practices for managing schemes? I’m a relatively new Jira site admin, and I’m still figuring out the right balance between using shared schemes and assigning individual schemes to specific projects.

I understand that a lot of it comes down to “it depends on the requirements,” but do you follow any guiding principles? For example, in another comment you mention restricting the "delete issues" to admins only.

Thanks for this write-up, and all the other contributions you've made to the forum. I've learned a lot from your answers and posts. 

[John Funk]

Thanks! @Susanna Babayan 

@MattD  - Thank you for your continued interaction with the articles/posts! And excellent suggestions as always. Yes, changing out Schemes can be a very dangerous thing and led to my biggest Jira embarrassment when I was first learning Jira. That might be a story to tell on LinkedIn  :-) Also, naming conventions are always good!

@Morgan Watts - Haha, I prefer "Dr. Funk" but but sadly I have not earned that title.  :-) 
As for best practices, for me the fewer schemes to get the job done the better. So, I try to create new projects based on existing Projects as much as possible. See my other article on "Project Templates" for more details. But if the project needs a unique and different Scheme, then by all means create and implement one. See Matt's comments about naming schemes and implementing/testing out in a sandbox environment - very helpful. 

[Hubert Kut]

The issue that I always had is that if I create a new project it creates all schemes unless you created shared config which I did not want. Anyway after switching to my naming convention you need to manually clean up created default one. I hated that. However now I use my app to do housekeeping and staying with only used schemes. "Dr. Funk" & "Doctor for Jira" sounds matching :)