Hey bf1084a1126e This is available for premium and Enterprise:

🆕 Action - Delay:

One of our most highly-requested automation features! Temporarily pause your automation rule before proceeding to the next step for up to 15 minutes.
For Jira Service Management Cloud Premium and Cloud Enterprise plans, as well as Jira Cloud Premium and Cloud Enterprise plans

Hello,

I still don't see it under actions. Is this still being rolled out, or is the feature not available in the free version of Jira?

Cheers

Awesome, thanks for this! Using it already!

Wow, finally we have something! Thanks!

Hi everyone,

Thank you for your continued feedback on this ticket! We’re excited to share that we’ve released a new delay action for Automation for Jira as a part of a new set of capabilities for alert and issue remediation.

This new feature enables you to add a ≤15 minute delay step into your automation rules—learn more in our announcement: https://community.atlassian.com/t5/Jira-Service-Management-articles/Automation-delay-action-new-3rd-party-connector-updates-are-now/ba-p/2756730#M4836

Thanks,
Makarand Gomashe
PM, Atlassian

This does not solve the auto-run issue.   I have 20 refetches in one automation rule.  I think there is a problem with delaying a rule to run when the database update isn't completed and the rule continues to the next statement.   I hoping the auto-run issue will be fixed and not just add another refetch.   Please increase priority on this.  

Adding a Delay action ... https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Delay

1) Does not solve the root cause / need to toggle serial and parallel rule execution, and / or adding a specific "wait until done" for actions which often occur asynchronously.  To learn more, see this suggestion: https://jira.atlassian.com/browse/AUTO-32

B) This new Delay action is only available for Premium and Enterprise license levels...which seems a continuation of the "upsell" drive which started with the changes to the packaging models for automation: https://www.atlassian.com/blog/announcements/cloud-automation-packaging-update

Definitely a game changer! Doing the happy dance! Thank you!

it looks like all the data centre versions of this ticket are closed out. Is there a current one, as we're on-prem and would love to have this available.

Thank you, thank you, thank you for getting this implemented!  Game changer!

Saw the 'Time Delay' new node in the automation rules now, this will make a big difference being able to pause an automation at a certain point.

The would enable us to do automations in Jira products without going out to a third party and then back to Jira.  Currently to do any delays (and yes there are cases when we have to) we have to perform automations in other software providers and then send back to Jira once completed.  This just causes more time to develop solutions along with the complications that it causes.  

That would be very powerful feature that would help us a lot! 

I see that this feature request is over 5 years old. Could it be possible to escalate this request to a higher priority. I'm an admin and end users are baffled why this is not already a feature. I don't want to be negative, but it seems like you guys are dropping the ball. Any reason why this is taking over 5 years to add?

We have automations where we have added multiple refetches and that has not helped. The automation this causes an issue for the most is triggered by an update to a Jira object field. If a user updates that Jira object field and the one immediately below it, the end result should be this automation does not meet conditions and will not send a notification. However, even if you update both within 5 seconds or less of each other the automation will trigger even with multiple re-fetches. We cannot adjust the order that we update these fields in because we have it setup to dynamically filter the 2nd field based on the 1st. We are eagerly awaiting this update as agents are getting email notifications that they should not be.

Will this new feature aliviate  https://jira.atlassian.com/browse/AUTO-32 ? We should be able to iterate a "Branch" in sequential order instead of parallel. We end up having to implement delays like described in this comment which makes the automation nondeterministic (even for the same input, can exhibit different behaviors on different runs)

https://jira.atlassian.com/browse/AUTO-32?focusedId=3343156&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-3343156 

I would think the infrastructure for an action like this already exists in some capacity because I can select the option to pause further actions until a response is received from an outgoing web request. Is there additional nuance or hesitation that's delaying () this feature. Even from a processing standpoint, it seems much preferable to repeated API calls to refresh an issue to artificially delay subsequent actions.

Man we need this functionality in Jira badly.  Come on Atlassian we need your help.  

+1

+1

I think both.

1. Create a delay function. (Love the httpbin delay option.)
   1. This could be used in some cases like adding the customer, or setting fields. Or other scenarios where the root cause has not been fixed yet. So this could be a nice bandaid to have in our arsenal.
2. Fix the root causes.
   1. The root cause mentioned below is interesting, being unable to set some variables until after a re-fetch. We have that too on one automation where I had to refetch. Fixing it so that refetch isn't necessary would be nice. Delay may not fix it.
   2. In my case, also, fixing the root cause would be good. There is an "add customer" automation step, which when the automation completes, the customer isn't fully ready to be used. We need a delay before we can set the reporter field to that customer email that was added. The "fix" here would be to make it so the add customer step doesn't complete until after the customer is ready to be used for setting the reporter field.

+1

+1!

+1

+1

Decent workaround:

Send web request

http://httpbin.org/delay/20

20 being seconds for it to wait to respond

Greetings!

In my opinion, the racetrack effect is a design problem / result of how the automation engine appears to use of the REST API functions, particularly during issue create / clone, as compared to how the UX code appears to do this:

1. issue created / cloned
2. then set the fields which could not (or were not) set with the previous step

If customers knew which fields are set in step 2, that would at least ensure we could adjust rules to add the Re-fetch Issue action when needed.

Adding a new delay action may not help address this racetrack problem.  Please instead investigate the root causes and address those.

Thank you!

So excited to see this issue move into "In Progress"

Hello Makarand,
Firstly, well done introducing yourself. Atlassian product management are generally absent from these inconvenient (for Atlassian) discussions.

The last time I invested 30 mins with Atlassian product Management (see JRACLOUD-70206; PM is Ahmud Auleear) the PM ghosted me after the session. No updates on the JAC, no replies to email, and NOTHING has happened with that JAC.

So what actions will you take after you get the feedback from folks that invest time?

Do you commit to (for example)

• summarising the feedback from contributors for all to see.
• pinning it at the top so it is not lost in the comments.
  ... convince us you will treat our time investment seriously?

In any case, as Product Manager, Jira Service Management you may be interested to know our Jira Service Management footprint is set to dive (in about 2 weeks) by 85% thanks to this dumpster fire >> https://community.atlassian.com/t5/Automation-articles/Introducing-our-new-packaging-model-for-Jira-Cloud-Automation/ba-p/2446099 . We are moving the business activity to one of your competitors.

Cheers
Andrew

Hi all,

I’m PM in the JSM team at Atlassian and working on enhancing Automation capabilities in JSM. A few of us at Atlassian are keen to know about your requirements with the delay/wait step in automation and how you plan to leverage it in usecases in IT Service and Operations management. 
So, I’m lining up customer conversations so we can understand your needs and solve this appropriately.
Would you be able to have a 30-minute Zoom call with us?
To book a time, please click on the link: https://calendly.com/makarandgomashe/delayed-execution

Looking forward to meeting you,
Makarand Gomashe
Product Manager, Jira Service Management

+1

+1

+1

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

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

+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.