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; } } }

Duplicate Company-owned board in isolation for test environment

Charisse Robison

I'd like to create a test environment to test different customizations and automations before creating them in production.

I have a company-owned project where I created a customized board using filters. I have created a new test project where I can selected the board, but I want to try changes to fields, automation and custom issues.

From my understanding, whatever I change on the new board would also be changed on the original board. This applies to schemes, issues, screens and so forth too.

Is there a way to copy to the board and configurations in isolation so I can use it as a sandbox?

Accepted answers

Trudy P Claspill

Hello @Charisse Robison

Have you populated your test project with its own set of issues?

Is the board for your test project referencing the issues in the test project, or is it referencing the issues in the original project?

You can make copies of all the Schemes and scheme components of the original project, and then associate those to the new project. That would enable you to test changes to those items without affecting the original project.

You can make copies of the Automation Rules that reference the original project, and change the copies to reference the test project. As long as the Automations are not Global and only reference the test project, then changes to the copies should not affect the original project.

You mentioned changing fields and custom issues. What type of changes do you want to make? Depending on the types of changes it may or may not be possible to do those in a way that would not affect the original project.

On a side note, if you upgraded to a Premium subscription you would have access to the Sandbox feature.

https://support.atlassian.com/organization-administration/docs/what-are-sandboxes/

All comments

Trudy P Claspill

Hello @Charisse Robison

Have you populated your test project with its own set of issues?

Is the board for your test project referencing the issues in the test project, or is it referencing the issues in the original project?

On a side note, if you upgraded to a Premium subscription you would have access to the Sandbox feature.

https://support.atlassian.com/organization-administration/docs/what-are-sandboxes/

Charisse Robison

I have not populated my test project with it’s own set of issues?

Is the board for your test project referencing the issues in the test project, or is it referencing the issues in the original project? I'd like for it to reference the issues in the original project.

Does making copies of schemes and scheme components mean copying all configurations individually such as issues, types layout screens fields, workflows all separately?

I think I'm trying to do something in an environment that I don't completely understand. I wonder if there's a training on setting up company-owned projects with all it's elements.

The developers are using tasks and subtasks for a larger story. Only the larger story will need to be tested so they don't want the QA to see their tasks and subtasks. Testing for them will be done inherently with the larger story. So they want to end their workflow after the development is done and not have it go through QA. Then QAs workflow would start at "Ready for Test". So I'm trying to come up with solutions for that while knowing just enough to get myself in trouble. I thought of having different task types for QA and Dev with different workflows. Then I thought about somehow flagging dev work and making it a different color and then just having the dev test go to done after they work on it. I am not sure the best path to take here.

I wish I could go premium but our budget just won't allow it.

Charisse Robison

@Trudy P Claspill Thank you. I look forward to your opinion.

Trudy P Claspill

I'd like for it to reference the issues in the original project.

If your new board references the issues in the original project, any changes you make to the data in those issues in the new board will be reflected in the original project/board.

If you want to test changes without affecting the original project and issues, you'll have to make copies of the issues or make new issues for testing in your new project, and have your new board references the new project and new issues.

Does making copies of schemes and scheme components mean copying all configurations individually such as issues, types layout screens fields, workflows all separately?

Yes, if you don't have an app that helps make copies of the configuration elements you would have to copy all of them individually and manually.

I think I'm trying to do something in an environment that I don't completely understand. I wonder if there's a training on setting up company-owned projects with all it's elements.

The use cases for projects in Jira is so varied that training could not possibly get specific enough to cover all use cases. Here is some basic information. Forgive me if you already know this.

Company Managed projects get their configuration from Schemes. Schemes are a way to map specific configurations for a particular feature to issue types. For instance, your may have multiple issues types in your projects. Some issue types need fields A, B, C, and D. Others don't need those fields but instead need W, X, Y, and Z. Two screens can be create; one with the first set of fields, and one with the second set. A Scheme can be used to map the first screen configuration to one issue type, and match the second screen configuration to a second issue type. That Scheme is then associated to your project.

The configuration elements in Schemes can be used in multiple schemes. You might take the same screens from above and associate them with different issues types in another Scheme, and use that Scheme for another project. If you change the screens, that affects both Schemes and affects the projects that use those Schemes.

Schemes themselves can be used by multiple Company Managed projects. When one Scheme is used by multiple projects, changes to that scheme will affect all projects that use that scheme.

Agile boards are just a way to view and manipulate issues. Each issue exists in one and only one project. Boards select the issues to display based on a filter. Multiple filters can reference the same issues, so an issue may display in more than one board at the same time. It is still just one issue though. Any change to that issue will be reflected in all boards that include that issue.

There is free, on-demand training available that you may find useful at Atlassian University - https://university.atlassian.com.

I'm going to start a separate reply to talk about the scenario you posed that lead you to start down this path. That will help keep the topic of managing configurations and addressing the underlying problem you are trying to solve separate.

Trudy P Claspill

On the topic of the underlying problem you are trying to address:

The developers are using tasks and subtasks for a larger story. Only the larger story will need to be tested so they don't want the QA to see their tasks and subtasks. Testing for them will be done inherently with the larger story. So they want to end their workflow after the development is done and not have it go through QA. Then QAs workflow would start at "Ready for Test". So I'm trying to come up with solutions for that while knowing just enough to get myself in trouble. I thought of having different task types for QA and Dev with different workflows. Then I thought about somehow flagging dev work and making it a different color and then just having the dev test go to done after they work on it. I am not sure the best path to take here

Are the teams working in Sprints or with Kanban boards?

You said the developers are using tasks and subtasks for a "larger story". Are they using Epics, or are they somehow relating their Tasks to another issue type? Can you provide any screen images to help illustrate the relationship between the Tasks and the "larger story"?

Are all the issues in a single Jira project or spread across multiple Jira projects?

What are the workflows for the issues? Do all issue types use the same workflow or do they use different workflows?

You can look at the Workflow Scheme for the project by going to Project Settings and selecting Workflows. If all the issues in the project use the same workflow you'll see information like this, naming one workflow and all the issue types.

Screenshot 2025-03-13 at 2.17.05 PM.png

If you can share copies of the workflow diagram(s) that would be helpful. You can click on the Status button for an issue and you should see a View Workflow option at the bottom of the list.

Screenshot 2025-03-13 at 2.19.33 PM.png

That will display the workflow diagram associated with the issue type you are viewing.

Charisse Robison

The team is working off a Kanban board.

They are using tasks and sub-tasks related to a story which will be what the QAs test. I don't have an illustration yet because the new workflow hasn't been determined. That's what I need to do and then create in Jira.

The issues will spread Across multiple projects which show on a single custom board created with queries.

As far as the workflow goes, that is what we are trying to figure out. I had suggested I create different issue types for dev tasks and QA tasks with different workflows but I'm not sure I could be successful pulling that off with the complexity of our board. This is what we have currently.

Workflow Scheme.jpg

All workflows for all projects and issues are the same. Task workflow.jpg

Nathan Phillips_kcvugf

Hello @Charisse Robison,

Thanks for reaching out on the community!

I wanted to quickly follow up here to provide some clarity in regards to how Boards work in Jira Cloud.

Boards in Jira Cloud are their own separate entity. The issues returned to a Board are directly based on the filter being used by that board, and the issues returned by that filter.

A board is not specifically tied to a specific project.

So when you mention:
"The issues will spread Across multiple projects which show on a single custom board created with queries.

As far as the workflow goes, that is what we are trying to figure out."

This can be the difficult part because the issues will behave specifically on the project they are created from. Your board is configured to pull issues from multiple projects, and each individual project may have it's own workflow, tied back to each issue.

If you know the workflow you want for each individual issue type, and that will never change, then creating a new workflow for each issue type in each project could be a good solution to ensure all issue types follow the same flow, regardless of the project.

If you continue to run into problems, let me know and we may end up opening a support ticket for more assistance!

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