Is there any way to get this prioritized higher and fixed.   I have now put 10 refetches in one automation rule due to this issue.  The automation rule runs over two minutes!!!  Very inefficient automation if we have to delay the automation rule 

Please - can we get this prioritized higher!!!

+1

@charlie Gavey, any hope for movement on this issue soon?

+1

This would be much appreciated since adding a manual delay with api slows down the instance.

+1

+1

+ 1

+1

+1

Merry Christmas to everyone and I wish us all that Atlassian has many New Year's resolutions - e.g. to solve this issue!

@PeterQuick

thanks for the info. I suspect it depends a lot on your use case for automations. In my case under service desk the browser is not involved at all. this should all be servers side. a process polls an email inbox and finds and email that triggers the creation of a ticket. the process of creating that tickets sets it's fields. and the process of fields being updated triggers the automation. There is no reason i can see that this entirely serverside process should ever run the event for a field updating without the related data. and even if the design calls for such a thing, I would expect the automation feature to handle those internal consierations without exposing them to the user.

I appreciate the various workaround options, the sla breach one is an interesting idea, thank you. I remain convinced that these are all the result of an underlying bug or fundamental design issue with automations. But regardless i'm happier to have workaround options than to not

btw. anyone interested in Automation - if you have not seen this discussion, you might find it interesting.
Atlassian have sent emails out about this change... so many are probably aware of Atlassian's PR, but the reality is a little different.
Introducing our new packaging model for Jira Cloud... - Atlassian Community

Hi @danielwould,

"why does the event trigger for the update if the automation can't read teh value at that point?" 

This is the way of webapps, your client browser tab has many states that rely on control events at a remote endpoint, mostly it sits in a wait state. This is a key difference between webapps and fat client apps and makes any comparison an apples-oranges thing. With Jira Automation you step through a door with a sign above - "Here be Dragons" - and get in touch with a common conundrum for webapp vendors; load-up the webapp so response to change is instant... suffer a bloated footprint at the client browser end and consume excessive resources and bandwidth.  

The "pause" action, or a "run in sequence" object is sorely needed in Automation. This behaviour is also evident in Workflow transition Post Functions and maybe one other spot I can't remember right now.

Hope this helps with understanding, as a "pause" work-around - for "Issue Created" use cases - I've been using SLA rules that breach after 7 minutes. The Automation Rule Trigger is SLA breached. The SLA breaches after 7 minutes, the rule kicks off. Everything up on the newly created request has settled by then, fields have values, data is intact. 

Cheers,

PeterQ

I was linked here by Jira support after hitting an issue with automations after we migrated to the cloud. basically I setup what in my mind was a trivial automation - trigger on change to field, check field contains value, if so do a thing. Which was not working and 'solved' by support by adding the refetch step.

Perhaps I'm missing something but I feel like this is just a bug in the way automation works. why does the event trigger for the update if the automation can't read teh value at that point? why would I as a customer have to know/guess that maybe just waiting a bit longer in an automation would work? I'm not sure why this feature request from 2019 was linked as if this helps. 

I would prefer that there was a fix for automation triggers that only fire the automation steps when the actual value relating to the specific field change being triggered on is actually available.

+1 for this feature

+1

+1

The One Atlassian Demo environment contains an example (Practice Standards) for creating Subtasks/Tasks from Assets. That's good.

But how can you demonstrate to a customer an automation with a set of sequentially created actions as subtasks if it's impossible—with Automation—to create them with sequential keys?

Imagine the reaction of a customer when they see a list of randomly ordered subtasks.

Additionally, the Subtasks panel does not allow for ordering using a custom field.

Just as there is a setting to allow a Web Request action to wait for the response, there should be a similar setting in the FOR EACH action .

+1

This issue fixed would be wonderful!   I have refetch all over the place since we have several automation rules.  Totally inefficient to put refetch in.   Why is the automation rules going on before the previous database update from a component isn't completed with storing a value!?

Can we please get this some priority?   Automation rules aren't a benefit if we are delaying them to run because the plugin hasn't allowed for the previous component to finish before continuing.

+1 for this feature. We use Forms for issue submission and have some fields linked to Jira field. We always have to add pauses via the re-fetch action to give the system time to place the data from the form field into the Jira field. Having the ability to have a timed delay would simplify our automation rules immensely. 

@Andrea Meroni's workaround is a logical one, but that will be problematic once the new automation measurements / pricing change comes into effect, no?   Since each run of the automation will be now be a success, and count towards the quota (I think, that's how it will be measured) this nearly doubles the usage on my scenario... the "sleep" I need is right before an "if / then" check, where about 50% of the time, no action is taken.

And on that same vein.... I can't recall...  Does "re-fetch" count as a success in an automation?

https://getsupport.atlassian.com/browse/PCS-214593

I'm not sure if it falls under this FR but having an option to run branches sequentially one after the other would be amazing. Just a button that meant that branches run one after the other...

Currently if there is a branch of 10 items, it runs every branch in parallel so you can't depend on previous task being completed before you attempt the next task.

I know this makes things run faster but it actually really limits how you can use automation. Please give us THE OPTION of runnin in seriel or parallel.

+1 on this – need the ability to wait n minutes within an automation before taking the next action. This would be useful when I am using conditions that have not yet been applied (pending another automation).

Hey guys! we need this!!! c'mon..

as suggested before, the faster WA is to send a web request (I'm using automation cloud) towards https://hub.dummyapis.com/delay?seconds=9 (in my case the time out is 9 seconds) Don't forget to check the "Delay execution of subsequent rule actions until we've received a response for this web request" flag

best, andrea

+1 please . I need this feature !!

I wish I could be shocked and say 'I can't believe this has been in REVIEWING for over a year and there has never been an update'... But I'm unfortunately I've seen too much. Although it does seem to be linked to https://codebarrel.atlassian.net/browse/ACF-12499 so maybe there is some active development going on for it?

My use case is that copying issue.properties.service-request-feedback-comment.comment to a custom field needs 'Re-fetch' actions added to allow enough time to pass for the value to be available for copying to a custom field.

As much as I agree that having a 'configurable' delay time functionality in Automation Rules is a feature request. 

The reason it's needed is that automation rules end up in race conditions with other system components which causes them not to work... Which is actually a bug right?

Anyway, it would be great to see this implemented / have an update on whether this is being worked on any time soon.

+1 for this feature, it would be very useful to have a pause/wait/sleep component for Jira automations

+1 for this feature, it would be very useful to have a pause/wait/sleep component for Jira automations

 
@ Eli Devlin added a comment - 11/May/2023 1:18 AM

For anyone desperately waiting for this, look into either Zapier or Power Automate. Using a Jira Automation rule, you can fire a webhook to either product, which can then execute a delay, before firing the webhook back to Jira, to trigger another Automation rule.

It's a bit clunky but it sure beats relying on re-fetching.

@Eli Devlin:

We gave this a try and implemented a "Delay API" in Azure with the possibilty to define the delay in seconds in the API call.

All for nuts.

Our friends from Atlassian intend to spare AWS consumption and add all delays

Action Details:
This rule execution exceeded the allowable service limits for Automation for Jira.View performance insights.

Automation for Jira has exceeded the total allowed processing time for this rule. Maximum allowed processing time over 12 hours (in seconds):

3600

@Atlassian: Some of us still try to love you. In the meantime we all pay.

@all: This issue is only in an early phase of evolution at the age of just over four years.

https://app.screencast.com/N6akCPGBJhOzX

In our Jira Server (v9.4.6) I see that the "Re-fetch issue data" automation action includes an optional delay of 0.5 or 1 or 5 seconds (default=no delay).

I can't tell from the Cloud documentation if that action has those features.

+1

This will be an amazing solution!!! Come on guys!!! please, release a pause component

https://codebarrel.atlassian.net/browse/ACF-12499

This is such a basic functionality. I expect it to be provided by the system itself, not by a 3rd party tool.

For anyone desperately waiting for this, look into either Zapier or Power Automate. Using a Jira Automation rule, you can fire a webhook to either product, which can then execute a delay, before firing the webhook back to Jira, to trigger another Automation rule.

It's a bit clunky but it sure beats relying on re-fetching.

+1
The number of re-fetch is not an exact value like wait(500).
In this case one could be sure that the automation will surely wait 500 milliseconds before continuing.

Please implement this ASAP.

Now we have to try, and add some more re-fetch hoping that it ill do the work.

BR, Levente

This is currently an issue with even native JSM features. Jira Forms, formerly Proforma before it was added to the main suite, set the value of fields linked to form elements after ticket creation. I have automation rules running that take different actions based on the value of the Jira field being set by the form. If I use the issue created trigger, the values set by the form submission are missing when the automation runs.

The only workarounds I've found are to have it run on a scheduled basis, throw a random unrelated JQL lookup in the middle to eat up execution time, or maybe have the automation re-fetch issue data several times before proceeding. None are great solutions. The first even has the chance of failing if you're unlucky enough for issues to be created when the scheduled run happens, but with the lookup completing before the issue is edited by proforma or another rule. Its less than a quarter second window, but its happened on our instance. 

+1

Hi Sue Lund,
In the Rule Details area (of any Rule) there's a tick-box to: "allow other rule actions to trigger this rule. Only enable this if you need this rule to execute in response to another rule."

This might suit your use case.
Cheers,
PeterQ

I would love to be able to tell it to run after a specific rule.  

+1

+1

+1

+1 ... this would be helpful in for each loop when you call webservices and want to make sure there is  enough delay between response and consecutive calls. 

+1 Please

+1

+1 

+1

+1

+1

+1

+1

+1

+1

Come on, guys, make it happen!

+1

+1

+1

+1 

...since migrating to cloud from server this has hit hard. With add-ons hosted away from Jira's ecosystem there's often one or more minutes before a newly submitted request/issue has all it's data intact. Automation rules triggered by issue create seldom have complete data.

Cheers,

PeterQ

+1

+1

+1

+1 for this suggestion, adding a delay action would be helpful in our instance.

+1 for this issue.

For context our scenario is that a rule is executing to create tickets in additional stakeholder projects however the trigger issue may or may not have attachments that need to be copied as well but they are still processing at the time of execution. The rule completes successfully but doesn't copy the attachments since they weren't part of the trigger issue at time of execution. Being able to delay processing for 5 minutes would solve this problem. As an aside I do worry it could introduce a backlog due to the creation multiple issues and that performance could be impacted as a result.

Note we are on Jira Server and I am voting here as a redirect from AUTO-54 which is closed as a duplicate even though these features don't always launch on the different platforms at the same time.

Edit: I was able to solve my problem with an if attachments exist condition in my automation and change it from running on issue creation to on a schedule. 

If we can't control the order of the jobs then please make it possible to execute an action after a certain time.

Thank you

Hi. Yes, adding a delay action would be beneficial. Thank you

It will be great if this could be resolved as this is affecting us a great deal.

Thanks

Another vote for this. I have an automation that is conflicting with ScriptRunner executions and a 30-second pause would probably resolve that issue.

+1

+1

+1

+1

hey guys, I've got a current workaround by just using a dummy API that will imitate a sleep function... not ideal, but it's what we have for now just a note that Jira times out automatically after 20 seconds, so don't set the delay seconds anything more than that! 

https://hub.dummyapis.com/delay?seconds=15

+1

+1

+1

+1

Needed please!

+1

+1

+1

+1

+1

+1

I also have this as a delay webhook after another webhook completes and pushes a new user to be able to search the new user.

Something like wait time or delay would solve the problem with Deep clone. We are automatically copying issues with attachments from service projects to software whenever the new software issue are created by requests and have to delete the original issue because we don't need it anymore. The automation deletes the issue faster than deepclone can copy them thus resulting not copying the attachments :/

@Yatish Madhav

Instead of updating the comment field on your issue directly, you could have Jira automation send an email to your mail handler. Then set a delay on your email processing for that specific handler and create another automation for when that email actually gets processed.

It's ugly, but should accomplish what you're trying to do.

+1 this would be a great action or attribute to current actions. I have an automoation to add a comment when someone is assigned an issue. BUT if there is 2 assignments on the issue through automation that is very quick, the comment is added with the wrong assignee detials

Please advise on this issue. Thank you

Bump, this would be a great feature

Have a similar use case to Rahul Chaudhari.

When a ticket is submitted, I'd like to give a 20 minute window for someone to pick up that ticket naturally. After a 20 minute window, I want the ticket to be assigned at random instead. I think I can achieve this now by creating an SLA for this and then use the SLA being breached as a trigger but than it muddles the SLA data.

We are using an add-on to update essential Azure attributes to tickets, we can't assign rules to run correctly as rules always get triggered before data is filled in the issue but the Azure AD sync add-on. Having a time delay definitely will be a win

This is super weird not to have this. This should be basic.

like nested ifs, breaks also missing.

We use some Extension, that need some time to re-fetch issue. Waiting additional minute or two after ticket is created would help us a lot. 
Simple feature to wait! I hope you can add this to Jira soon  

Looking for this as well. Have to make calls to API's for analysis and could take 15s+ before an appropriate response is available. 

Hi, 

I use a DateTime customfield to get SLAs "time to resolution" value depending on other fields. Automation's triggers like "issue create", "field value changed" or "Issue update" can not fetch SLAs value in time, with "refetch issue data" or not. Indeed, SLAs are calculated by Jira with a delay.

So my custom field DateTime is never updated with SLAs "time to resolution" value.

I found a workaround : schedule an update every 5 minutes with Automation.

Of course, I would prefer to add a delay, combined with "Field value changed" trigger.

Regards

The ability to introduce a delay in the automation rule is and will be vital in use with third-part add-ons like Proforma!  We are finding that the field population is taking longer than a "refetch issue data" automation step will provide.

This appears to be a pretty major problem. Any automation using Advanced Branching with a list of items (i.e., For each: Smart value) is fundamentally broken.  It doesn't seem to matter how the list is generated, I've tried numerous options. Currently, I'm using match().

In the For each loop, I'm attempting to add values to a multi-select field. It's apparent there's a race condition because anytime there is more than two items in the loop, I end up with a random selection of items added to the multi-select field, but only ever two items. With stacking re-fetches, I can can sometimes push this to 3 or 4 items, but all items are never added.

For simplicity and extra testing, I decided to add a comment corresponding to each item in my list (rather than add values to a multiselect field). I only ever get 1 comment added. Again, stacking re-fetches sometimes seem to help, but the final answer is always incomplete and wrong.