ad92d87fa335 could you make a [community post|http://example.com] of what you've described?

Here is not the appropriate place to discuss your issue. On the Atlassian community, you can provide additional details and images, and there is a broader audience available to assist you.

Thank you

ad92d87fa335 I wonder if you should also add in a "re-fetch" action to that rule after the delay.  Make sure it is grabbing the updated database values from the issue after it settles in after the delay.  It could be that your delay is working, but then the rule continues processing with the issue data it has stored at the moment of it triggering (I think the delay just waits with data it already had from the beginning).  Just an idea... maybe you are already doing that and Atlassian Support can help.

73598c92e650 so a more complete description of what I'm doing would be this, and I think this was in a branch, yes. I'm pretty sure I did try this as an isolated rule with the same issue with Delay not doing what I was expecting it to do.

ea582e71db54 I see what you mean re pausing the timer as well as the subsequent actions, that sounds logical at least for the time being logged. That said, I think when I was following the logs I wasn't perceiving the delay as happening. Granted that does open things up to PEBCAK being the explanation.

So for more detail on what I'm trying to achieve... and update how I'm working around it.

Scenario: When certain requests are received, they require approval from the user's manager. We want to ensure that this approval is sought consistently.

What I'm trying to do: Upon a particular service request being logged in service management, automation determines and sets the appropriate approvals required for the service request, and transitions the request to seek approval from said user.

The how:

Action triggers upon issue creation, a number of IF conditions to narrow down to certain issues being created.

Delay added for 60 seconds.

Then actions take place. There's a web call to the API to get a user ID based on the simple text value of a field in the created issue (it takes the first userID displayed in the query result). That field is populated at the time of creation by a third party add-on which pulls user information from AD attributes (in this case, the user's manager, as defined in AD).

The above action sets a variable for that user ID, which is then used by the next action to set a user picker field for approvers. The issue is then transitioned to seek approval from the user in the approvers field.

The problem is that if the AD attribute isn't populated into the text field, then the API call queries with a blank value. The result of this is the complete user list from the instance, so the first value there is the first user listed in AD. Consequently, no matter who raises the ticket, and what value is pulled from AD in to the custom field, all tickets get assigned to this first person in list, which is not the desired effect.

For this reason I tried adding the delay, since although the AD attribute sync is fast and according to history does populate the field before the rest of the actions take place, I tried to give the automation more margin to let that field be populated before moving on to the next actions. But no matter how long the delay, I still run into the same problem. And when following the audit log live during testing, I'm not seeing the turn around time of the automation be longer than the requested delay.

Since typing this all up I've implemented a work around that does get the result, BUT it does mean having a separate automation rule for this.

I've done this through moving the actions described above to a separate rule that is triggered upon the specific custom field being changed (which then gets triggered when the add-on populates it) and with the condition that the Approvers field does not already have a value (as well as the request type conditions, etc etc, to narrow down further). This does mean, though, that I'm using up two automation credits instead of one for these request types, which isn't ideal.

73598c92e650 and ad92d87fa335 , I would think that it does not add run-time to the rule (or else we would all run into the 60 minutes per 12 hour total allowed processing time very quickly if our delays are long).  My guess is that it delays before the next action, but essentially pauses everything, including the measurement of processing time since it is just waiting before going to the next part of the rule and the timer will begin again at that time too.

ad92d87fa335 did you use the delay in a branch? Then this can happen. Since branches run in parallel.

If it is not in a branch, then it is quite strange.

I'm not convinced that this Delay component (in Cloud) is working in automation, as I have set a delay of 30 seconds in one rule, and yet the rule completes in under 7 seconds. 

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!

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

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