Time delay on automation rule executing - posting field value as a comment

[Dylan Moore]

Hi All,

We have a custom field set-up for status updates, where we are asking project leads to provide an update on epics once a fortnight (or when a significant update occurs). Our CTO has asked that when the status update field is updated, it is automatically posted as a comment. 

While this is a fairly easy automation, i would prefer to add in a time delay of say 5mins. Reason being is that if someone is writing their update, submits it and then realizes they need to make a small change (maybe add a sentence, fix a typo etc.). The 5min delay (grace period) basically just stops multiple almost identical comments being posted. 

The expected end result is that the epic has a bunch of historically dated comments which are status updates and can be read similar to a twitter (X) feed. I am well aware that activity feed with filter set to all would show this but it can be very noisy with all the other updates going on.

[Dylan Moore · Accepted solution]

Atlassian as of a few days ago have rolled out a delay functionality up to 15mins. I'm yet to play with this and verify its behaviour but the concept looks promising. Pinning this as the answer for now and will report back with results once i have tested.

https://community.atlassian.com/t5/Jira-Service-Management-articles/Automation-delay-action-new-3rd-party-connector-updates-are-now/ba-p/2756730#M4836 

[Cory Hoover]

I use the Scheduled trigger and run a daily task (or as often as needed). So using a Basic Scheduled trigger, I set the start date and time to the when i want it to become active, for example the time I created the trigger, then I set the occurrence to run as often as needed, for example every 1 day at 8:00am. 

The key aspect is to use a JQL search such as 'status = "24 Hour Hold" and updated < -1d'. 

In theory, this should check all tickets in the 24 Hour Hold status each morning and if they have not been updated in 24 hours, it will transition them to our 'reopened' status which is our 'then' in the rule. 

[Dylan Moore]

Thanks @Cory Hoover! This is a really creative solution and one i hadn't thought of before. There used to be some limitations around the number/frequency of scheduled automations but they seem to be relaxed (or im just imagining it). 

As of a few days ago atlassian have added a delay functionality (up to 15mins) as per this request ticket. I've pinned my answer above with a bit more info, I intend to report back once I've had a bit of a play with it and share my findings. More info here:
https://community.atlassian.com/t5/Jira-Service-Management-articles/Automation-delay-action-new-3rd-party-connector-updates-are-now/ba-p/2756730#M4836

[Charlie Gavey]

Hi @Dylan Moore

I’ve linked your suggestion to a related feature request, which counts as an upvote for this ticket:

https://jira.atlassian.com/browse/AUTO-238

If you’d like to chat to the Automation team, we’re always happy to learn more about how you’re using Automation and how we can improve - feel free to book a time that suits: https://calendly.com/cgavey/automation-feedback

Cheers,

Charlie

[Pablo]

hi

pitty that today there are random delays everywhere;/

https://jira-service-management.status.atlassian.com/

i just hope all automations are executed 

[Darryl Lee]

OUCH!

[Dylan Moore]

ZING!

[Darryl Lee]

So there's a hack that I've used before, making a web request to an external website:

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

(It turns out I was not the first person to come up with this workaround: AUTO-238)

The caution is that there is a 5 minute maximum execution time for automation rules:

• Automation service limits 

So maybe you can do 4 minutes to be safe.

[Dylan Moore]

Thanks @Darryl Lee ! Do you know if theres another trigger of the same rule on the same ticket within the 4mins, will it essentially kill the original trigger?

I.e. - I update status update field, then 2mins later come back and edit a sentence. Will i still end up with 2x comments being posted each after the 4min delay or only the later comment?

[Darryl Lee]

Doh. You're absolutely right. It'll send two messages. 

I THINK maybe you need to do another check to see if there have been more than one changes to the Status Update field in the last 4 minutes, and if so then do NOT add a comment. I wonder if this is possible by hitting the issue history API... I'm typing on my phone. Will check in a bit. 

[Darryl Lee]

So I looked at the changelog API endpoint and I think it might have what we'd need.

When 4 min is up, you'd need to do a web request to:

https://YOURSITE.atlassian.net/rest/api/3/issue/{issueIdOrKey}/changelog?maxResults=100

(You will want to tune that # to balance the max number of changes to a ticket vs load time for the API call. I wish the changes were in reverse chronological order so we didn't have to grab so many.)

And using Advanced branching I then iterate through each changed item, like so:

So we need to check if there was a change to the Status Update field and if it was within the last 4 minutes. I guess after the 4 min delay, the next step should be to note that time:

Smart value variable: {{FourMinAgo}} = {{now.minusMinutes(4)}}

THEN, using Advanced compare condition we can check if it is the particular field:

{{change.items.first.field}}: Your Field Name

AND we can also compare the timestamp, but here's where I'm running into problems. I came up with this Smart value:

{{FourMinAgo.toDate.isBefore(change.created.toDate.convertToTimeZone("UTC"))}}

When I test this and look at the Audit logs, I'm seeing it switch to true, but I can't seem to get the comparison to work for booleans.

AND ANOTHER problem is that even if I got it to work, there's no "exit()" action to call, and I tried setting a {{nogo}} variable to 1 within the iteration, that does NOT seem to be globally accessible. (And I even added another 15-second delay to allow it to get "set".)

I'm sure there's some way to flip this logic, but that kind of thing always hurts my head. I'm sending out the Bat-Signal to @Bill Sheboy to see if he has any ideas. 

[Bill Sheboy]

Hi @Dylan Moore and @Darryl Lee 

If I am understanding your scenario, what you are trying to do is create a running project work activity report log, using automation rules as follows:

• Epics have a custom field named Status Update.  Assumption: this is a text field.
• A project lead person enters text to summarize progress
• That person enters information at least every 2 weeks
• They could post more frequently if something significant happens
• Changes to Status Update are captured and posted as a new comment
• One challenge: corrections / updates can be made to the Status Update field, and when an automation rule is triggered on a change to the field to capture the comment, apparent near-duplicate comments are created.  Proposed solution: delay the step of capturing Status Update to create the comment for some time interval.

The above described solution approach can create a race-track problem.  A few alternatives are listed below:

• Separate the reporting and comment logging cadences
  • What if the logging of comments only happened once per day, for example just after midnight, with a scheduled rule trigger?
  • Then as long as no one is updating the field around midnight, the log has one entry per day usually
  • A separate, manually triggered rule could be used for any exceptions that need an extra "significant event" log entry
• "Are you really sure" before logging a comment to slow down the human flow steps
  • Have 2 fields: Status Update, and a checkbox for Status Update Ready
  • This is also a human process change, where the project lead slows down a bit to ponder, "Is my Status Update ready to be logged"?
  • When they are ready, they check the box, and...
  • Change the rule trigger to watch for a change to Status Update Ready
  • After the comment is logged the checkbox is cleared
• Self-correcting, to keep the log entries to one per day
  • The log entry comments need some formatting/content which allows them to be searched for and found.  Let's call that the "log indicator".  Perhaps also have a separate indicator for "significant events" logging.
  • Rule still triggers on changes to Status Update, and immediately after the trigger, a Re-fetch Issue action is added to slow the rule down a bit
  • After the re-fetch action, use smart value, list filtering to find any comments added today which also have the "log indicator", and capture their comment id
  • If any such comments were found, delete them
  • Add the new comment

Kind regards,
Bill