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

What's best? Automation or rules in the workflow editor to pre-set fields?

Morgan Watts_9u2pqd

Hello all,

I'm curious to see the opinions on what the best way is to pre-set fields on issue creation. Writing an automation rule or using rules in the workflow editor?

Currently, I have three rules in the new workflow editor to fire upon creation of a specific issue type that fills three fields with three separate links.

I would like to do the same with specific users to specific fields, but these users change depending on the parent the issue card is linked to at creation. I don't know if in the new workflow editor you can use smart values or if I must select a singular specific user.

Which led to me to my old reliable of just writing an automation rule that triggers on creation to edit these fields with the necessary information.

I'm new to Jira and don't have a solid understanding of which is better? I'm leaning more towards ol' reliable "it depends" as I found with these use-case, but maybe I'm missing something?

I know automation rules count towards my actions per month, but our company is small and definitely not going to hit our monthly limit so that's not really a con. Past that, I don't see a clear reason why I should use workflow editor rules over automations. If someone has a good example, I'd love to learn!

Accepted answers

Bill Sheboy

Hi @Morgan Watts

Although many common scenarios can be solved by both Jira Automation and Workflows, in my understanding of both, there are distinctions in what is supported. A few such distinctions are:

workflows can have validators before an event / transition proceeds and actions before or after the transition
automation rules (usually) trigger only after an event occurs
it is possible a workflow function could consistently succeed while an automation engine outage might prevent the automation rule from triggering when expected; and...I have found no definitions in Atlassian documentation of which events will still trigger rules after an outage. That level of outage seems to be quite rare.
default / pre-set values can be handled in other ways than workflows or automation rules, depending upon your project type and field setting needs; for example, default field values or marketplace addons for template issues.

Please consider what problem you are trying to solve for each scenario and that may help decide which mechanism to use to set the fields.

Kind regards,
Bill

All comments

Shawn Doyle - ReleaseTEAM

It depends. I'm using more automations these days whereas I would always create triggers, conditions, and validators before.

I can see the day that Automation takes over the traditional workflow methods. I think you are safe sticking with Automations, beware to keep track of how many are firing and stay under the limit.

Bill Sheboy

Hi @Morgan Watts

Although many common scenarios can be solved by both Jira Automation and Workflows, in my understanding of both, there are distinctions in what is supported. A few such distinctions are:

workflows can have validators before an event / transition proceeds and actions before or after the transition
automation rules (usually) trigger only after an event occurs
it is possible a workflow function could consistently succeed while an automation engine outage might prevent the automation rule from triggering when expected; and...I have found no definitions in Atlassian documentation of which events will still trigger rules after an outage. That level of outage seems to be quite rare.
default / pre-set values can be handled in other ways than workflows or automation rules, depending upon your project type and field setting needs; for example, default field values or marketplace addons for template issues.

Please consider what problem you are trying to solve for each scenario and that may help decide which mechanism to use to set the fields.

Kind regards,
Bill

Morgan Watts_9u2pqd

Hello @Bill Sheboy

Thanks for detailed response. Honestly, never even thought about what happens if automation has an outage, didn't even consider that a risk haha.

Good points on the validators being before/after. I've use workflows to add validators of "user must be in this group" or "field must contain this value" but there's been limited requests that require that level of effort.

Thanks again for the information Always love learning more about Jira.

Warm Regards,

Morgan Watts

Morgan Watts_9u2pqd

Hello @Shawn Doyle - ReleaseTEAM

Thanks for the response! Yes, I'm in a similar situation where I've found automation can handle most of the requests I get. Thankfully my company is quite small so I think hitting the automation limit will take a lot of effort on my part (or just poor automation writing), but it is something to consider.

That's partially why I asked this question. If I can remove some automation actions and put that into a workflow, it'll potentially save me from headaches further down the line.

Marcela Junyent_scufs0

Hi, I wanted to share my thoughts on the comparison between workflows and automations. I believe that both have their own unique strengths and are better suited for different scenarios. It's also important to consider whether you have an add-on like JWME or a similar tool, as it can impact your decision.
I've encountered some challenges with the synchronization between post-functions and automations in complex business logic. That requires the use of “Delay” action on both sides.
In this specific use case that was presented to me, I would lean towards implementing the automation solution and maintaining the workflow in its current state. To keep business logic simpler to audit in the automation log and alerts. As long as you don’t have the limit restriction risk.

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