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 test new automations for big Jira projects?

Roman S_yc0h50

Hello,

I have a few projects that help me organize business processes.

For example, for onboarding, I have a separate project called "Onboarding," where different teams (HR, SysAdmins, Facilities, etc.) work on each new onboarding card.

All the teams have their own requests regarding what they want to update, automate, or add to the process. As a result, in the "Onboarding" project, I have dozens of automations, and when I add something new, it can break other logic.

So I need a test environment where I can add, remove, change, and test automations without sending notifications to all members involved in the process.

I tried using Jira Sandbox, but it didn’t copy my automations—just the project cards.

How can I organize automations-test process?

Accepted answers

All comments

Tomislav Tobijas

Hi @Roman S ,

Indeed data copied from production to sandbox does not include automation rules. You can vote for this feature here: CLOUD-11161: Data copied from production to sandbox does not include the Jira automation rule data

Regarding how to test that out, you might want to check out the following support article: Import and export Jira automation rules. Basically, you can manually export and reimport automation rules from production to the sandbox site. Depending on the number of automations this might take some time, but from my experience, it's still the fastest way to get that copied as well.

The other option would be to create a 'sandbox' project in your production site. You can create a new project by copying the existing "Onboarding" project configuration and then just copy automation rules from "Onboarding" to a new project, or change the rule scope to cover both projects.

Hope this helps.

Cheers,
Tom

Shiva Kumar Hiremath

Hello Roman,

You can export the Automation from the production environment and import to sandbox environment.please accept the Answer if it works for you.

Roman S_yc0h50

@Shiva Kumar Hiremath , thank you for answer.

Yes, I tried it, but there are a few big projects (~10) in our jira and almost all of them have updates every week.

So I need to make export-import to test env -> make a work, test result -> make export-import back. I would like to find some more automatic/easy way

Roman S_yc0h50

Hello, @Tomislav Tobijas , thank you!

"The other option would be to create a 'sandbox' project in your production site"

In this case, can I test automations without notifying other members of the process?

Some tasks should be assigned to HR. I would like to test that they are correctly assigned to HR, but without sending notifications to them from the test environment project.

Tomislav Tobijas

@Roman S , just use a different notification scheme for that project (e.g. make an 'empty one' and no notifications should come out; that's if you don't have any specific ones that automation actions are sending out, like 'send email' action or such).

Atlass Monster

@Roman S I suggest if you go on large scale to use additional tools for Automation. First they will make your automations more powerful and second they are more versatile for testing and replicating. You can do your own research on the marketplace.

Atlassian seems to have some APIs available for "Autmations" : https://developer.atlassian.com/cloud/automation/rest/intro/#about

They don't much but perhaps one day they will and it will be the proper way to solve your problems.

Kamei Ryosuke

Old thread, but it still comes up first in search for this, so for whoever lands here.

Atlassian still hasn't shipped a dry run for Automation. AUTO-170 (https://jira.atlassian.com/browse/AUTO-170) has been open since 2020 and sits at Future Consideration. That leaves shrinking the blast radius, and the sandbox route Tomislav describes is the biggest version of that. When the export/import cycle is too slow for the rule I'm iterating on, I do the following inside production.

Start the rule against one issue you own. For a scheduled rule, set the JQL to key = ABC-123, run it, read the audit log, then widen the query. It's crude, but you watch the real rule act on a real issue without touching anyone else's work.

Put Log actions where the real actions will go. Instead of Edit or Comment, add a Log action that prints the smart values you're about to write, and read the audit log to see what the rule would have done. Once the log reads right, swap in the real action. I leave the Log in afterwards because it makes the rule far easier to debug six months later.

Turn off the update email while you test. On Edit issue, open More options and uncheck "Send email when the issue is updated". That covers the part of your question about the team hearing about it.

{{#debug}} around any smart value you're unsure about prints the resolved value to the audit log.

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

automation

sandbox