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!

Wow, finally we have something! Thanks!