Specifying Work Item Types for which an automation rule is triggered

[Graeme Wright]

I have a rule that is triggered when the Parent field is updated on a work item and a condition that only follows through on the rule if the work item type = Epic.

However, the rule still triggers for all work item types when the Parent field is updated. For non-Epics it takes a fraction of a second before it hits the Type=Epic condition but this is unnecessary processing load for stories, tasks etc.

Is there any way to specify, in the Rule Details?, which work item types are relevant, like we can specify which Spaces are relevant to the rule, so the rule will not even trigger when, say, the parent field on a story is updated?

[Bill Sheboy]

Hi @Graeme Wright 

Without seeing the specifics of your complete rule and audit log details for context...

I wonder if you have a condition in the trigger, and that is producing inconsistent results because of the known racetrack timing problems in some rule triggers.  That is, the event fires which triggers the rule before the data is stable enough for use in the rule steps.

For this reason, I recommend not using any conditions in triggers.  Instead, use separate conditions after the trigger. 

And for some specific triggers such as Work Item Created, an additional mitigation is needed: add a Re-fetch Work Item Data action immediately after the trigger and before any other steps.  That will slow the rule slightly and reload the data before the steps proceed.  Both the slowing and reload are needed; this is why the Delay action will not help for such symptoms.

Kind regards,
Bill

[Graeme Wright]

Hi Bill - Thanks for taking the time to respond.

What I am trying to avoid is the rule triggering at all, if the work item type is not an Epic. Currently, because the Parent field exists on all work item types, it is triggering for stories, tasks, sub-tasks etc. only to be stopped when it hits the condition.

Your suggestion to move the Type=Epic condition to after the trigger, would not address this.

I have a feeling this is probably going to be an enhancement request to Atlassian to, in my thinking, add another field on the Rule Details form i.e. where we can currently list the Spaces that are in scope for the rule, add a field where we can select one of more work items types that are in scope for the rule - or leave it as All Types.

Regards,

Graeme

[Bill Sheboy]

My understanding is: Atlassian knows about the racetrack timing defects, acknowledges this will take architectural changes to fix, and provides no timeline when that will happen.  That was their response when I noted the symptoms with the release of conditions on triggers.

For some rule triggers, adding a condition on work item type "might" work.  If you are testing only the trigger work item's type, that is more likely to work when the Parent field is the only thing that changed.  If the field changed as the result of a move, work item create, drag-and-drop operation, or workflow action, perhaps not so much.

In my opinion, the only reason Atlassian may have implemented the feature to add conditions on triggers was to reduce entries in the customer's audit log.  The feature has no impact on monthly usage limits; that is, if a condition would have stopped the rule before any actions which "count" towards usage, there is no usage impact...only log entries.

Conversely, there are several community posts where people see this lack of audit log entries for conditions on triggers causing more harm than good: they lead to extra work by rule-writers trying to understand when / why a rule did not run when expected.  I recall there are JAC suggestions to add to the audit log an entry to show which conditions were not met when a rule doesn't run in such cases.

[Marc -Devoteam-]

Hi @Graeme Wright 

No this is not possible, as the trigger defines the execution of the rule.

You could change the scope of the rule, based on which space this is related to.