In a workflow I can create rules for Triggers, Conditions, Validators and Post functions. I would like to know where in this sequence do workflow-triggered Jira Automations take place. Specifically, if I create an automation that triggers on "Issue created", is it triggered after all the workflow Post functions are triggered, or earlier?
PS. Wouldn't it be nice if workflow-triggered automations showed up in the list of workflow rules?
For every transition in a workflow, you will have at least one post-function which fires an event, for example, Issue Created on the create transition and Generic Event for all others unless you modify these.
If you use an "Issue Created" trigger in your automation rule, then it is processed when the Issue Created event is processed in the post function.
If you use an "Issue Transitioned" trigger, then these will be processed when the event post function in the transition is processed.
As a wrote below, apparently the Automation rule is always run after all of the post-functions are executed, regardless of where in the sequence of post-functions the "Fire event" happens. This I have verified with Atlassian in support case JST-627992.
However, the behaviour is ambiguous and I would like to see an explicit explanation of this in the docs.
In a Jira workflow, the entire transition is wrapped inside a transaction, which is only committed after the last post function has completed successfully.
In the source code (available if you have a Jira Server license), in the com.atlassian.jira.workflow.function.event.FireIssueEventFunction class, you will see a call to the IssueEventManager.dispatchIssueEventBundleOnCommit() function, which basically will fire all events processed during the transition at the point the transaction is committed.
This is consistent with the behaviour you have experienced.
That's why you also have post functions in the workflow. These happen when the transition has happened. You can see them for a specific transition in your workflow along with their order.
Automation rules are like listeners that can do something based on an event related to issues (created, commented) or other events (version releases). You can use tags in your rules to quickly filter issues that are triggered from issue transition events.
Automation rules are not really triggered by the workflows only. It is the events like issue creation, transition, edit issues, assignment etc. There are many events can happen without workflows as well. For workflow transitions you can find one essential post function called "Fire a Generic Event.." which can be processed by the listeners.
In my experience it happens after the post-functions. Or well, that's the assumption we're going off of.
You could test it by setting a field value in a post-function, and then log that field value in an Automation rule.
If we're to believe what the triggers say, they fire "AFTER" the event (issue created/transitioned, field changed, etc.), and so the audit logs should show what your post-function set.
If not... then Automation is firing sometime before then, but that would be... weird, and I'm sure we'd see a lot more complaints about it here. :-}
Let us know.
Just finished a discussion with Atlassian support. We set up the following test:
When the issue was transitioned, the issue was first assigned to the reporter and then assigned to the other user, which matches your experience/assumption.
No conclusion can be drawn about a relationship between firing events and the triggering of automation rules.
Still, I think Atlassian could do more to clarify how this works officially.
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events