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 build a new workflow without affecting existing workflows, screens and issues?

Phil Bustin_7fmhjs

I plan to build three workflows in Production. I built and tested these workflows in the Sandbox.

Can the workflow, with its states, transitions, custom fields, screens and automations, be built in Production without affecting existing workflows, screens and issues? Would the procedure be to avoid linking the new components to schemes?

It would appear that in the Sandbox, as I built and linked the new workflows, existing issues and screens were not affected. For instance, I created dozens of new custom fields, and these did not appear in existing issue views. The trickiest part of building the workflows in the Sandbox was avoiding using states that existed in other workflows.

Is there a step-by-step guide for building the new workflows and their components with no or minimal impact on existing workflows?

Accepted answers

Trudy P Claspill

Hello @Phil Bustin

As you found in your sandbox it is possible to build new workflows without impacting existing workflows and issues.

Is there a step by step guide for this? I don't think there is. The basic concept is to create new items and not make changes to any pre-existing items.

For workflows you create new workflows and add them to new workflow schemes. You actually can reuse Status values in multiple workflows without impacting other workflows that use those same Status values. As long as you new workflows are not associated to existing workflow schemes, and as long as your new workflow schemes are not associated to any projects, then existing workflows and issues should not be impacted.

For screens again make sure you are creating net new screens, screen schemes, and issue type screen scheme configurations.

You can add new custom fields (for use in Company Managed projects) without impacting existing issues and screens by simply not adding those custom fields to existing screens or to Field Configurations that are in use by your current projects. The latter may be trickier if your projects are using the Default Field Configuration. All new custom fields are added to the Default Field Configuration. If your projects leverage that, then the fields will be available to them even if the fields are not visible on the screens.

To limit the impact of Automation Rules you must ensure that the Project Scope of the rule is set so that it won't affect unintended projects.

Ismael Jimoh

Hi @Phil Bustin

You have most of the steps already figured out.

You can create the custom fields, screens etc. and normally provided no project uses the default field configuration, field configuration scheme, etc.

I will confirm this first because projects that tend to use the default may have the fields automatically added.

Do not rename statuses you are using?
Do not use existing configuration and modify them in anyway as they’ll impact existing projects using these

So long as you consider these, typically there shouldn’t be an issue.

Before proceeding, let me ask you mentioned you had a sandbox, typically if you are very certain there was no impact in sandbox and no one has made changes to production instance since the sandbox was created then there should be no problem.

All comments

Trudy P Claspill

Hello @Phil Bustin

As you found in your sandbox it is possible to build new workflows without impacting existing workflows and issues.

Is there a step by step guide for this? I don't think there is. The basic concept is to create new items and not make changes to any pre-existing items.

For screens again make sure you are creating net new screens, screen schemes, and issue type screen scheme configurations.

To limit the impact of Automation Rules you must ensure that the Project Scope of the rule is set so that it won't affect unintended projects.

Ismael Jimoh

Hi @Phil Bustin

You have most of the steps already figured out.

You can create the custom fields, screens etc. and normally provided no project uses the default field configuration, field configuration scheme, etc.

I will confirm this first because projects that tend to use the default may have the fields automatically added.

Do not rename statuses you are using?
Do not use existing configuration and modify them in anyway as they’ll impact existing projects using these

So long as you consider these, typically there shouldn’t be an issue.

Phil Bustin_7fmhjs

The eventual goal is to link the new workflows to existing workflow schemes, so that the new issue type can be selected by the User if not in fact selected by default, to replace an existing workflow. I guess that decision has to be made, and if it's by default, I would replace the existing workflow in the workflow scheme with the new one, on a weekend. If it's by choice, I would add the new workflow to the existing workflow scheme, as I did in the Sandbox. I think the same principle would apply to screen schemes.

Is an alternative to use a new workflow scheme regardless of whether the new workflow is going to replace the old, and if it's going to replace the old, then just remove the old workflow from the old workflow scheme? If that would work, I guess it means that a project would have two workflow schemes. Incidentally, the new workflow will be used by 4 projects. (Hope my terminology/understanding is accurate.)

Trudy P Claspill

A workflow defines the Statuses through which an issue can transition, and rules/actions associated with those transitions.

A workflow scheme associates workflows to issue types. A Workflow Scheme will always have a Default workflow specified. That is the Workflow that will be used for any issue type that has not been explicitly associated to a workflow within the workflow scheme.

Within a given workflow scheme an issue type can be associated to one and only one workflow.

A project can have one and only one workflow scheme.

There is a similar relationship between screen schemes and issue type screen schemes, and between field configurations and field configuration schemes. Each each an issue type is being associated to a configuration that will govern interaction with that issue type.

What is the overall change you are trying to make? It sounds like you might be trying to add a new issue type to your projects, and provide a new workflow and new screens for that new issue type. If that is your goal, you can add the new workflow to the existing workflow scheme and associate it to the new issue type. That will not affect the other issue types and their workflows. Similarly you can create a new Screen Scheme and add it to an existing Issue Type Screen Scheme, associating it to the new issue type. If that Issue Type has not yet been added to the project itself, that is okay.

One thing to note is you said you created new "states", by which I assume you mean new Status values. When you add the workflow(s) that use those new Status values to your project(s), you are going to have to update the agile boards that you use with those projects. The new Status values will go to the Unmapped Statuses for those boards. You will have to map those new Status values to columns, otherwise issues that you assign to those Status values won't appear in your boards or backlogs.

Phil Bustin_7fmhjs

Thank you.

In the Sandbox, I did in fact add a new issue type, so I'll be doing the same in Prod.

Yes, in the Sandbox, I added the new statuses to the boards. I'll add that action to my checklist.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud

workflow