Optimization of automation for service requests

[Dimitrios Kouroumichakis]

WishTarget:

Once the first two tasks have been completed, only then should all other service requests be allowed. These are selected via checkboxes in the form.


Current status: Currently, with the new automation (see illustration), the first service request is processed when the first task is completed. And when the second task is completed, the second service request is executed. This is exactly what I don't want. 😕

Can anyone give me a tip on the best way to solve this problem?
Thank you very much.

[Bill Sheboy]

Hi @Dimitrios Kouroumichakis 

For an automation question, it helps to post your rule in a single continuous image rather than in separate images.  From what you show it is difficult to understand what is happening.

Please try using a screen capture tool or a browser addon for scrolling page capture and re-post your rule image.  And, please post an image of the audit log details showing the rule execution.

Until we see those...

Your rule appears to use the Smart Values Condition to test if the related Sub-tasks are in the Done / Completed status, using a list iteration.  That could produce a list of zero-to-many "true" values, and so will not match what you show for the second value in the condition.

Instead, consider using the Related Issues Condition with a JQL expression to check the other Sub-tasks.

Kind regards,
Bill

[Dimitrios Kouroumichakis]

Hallo @Bill Sheboy und @Marc - Devoteam 

Thank you in advance for getting in touch with me.

I will first send you the first two automations (TASKS) that work perfectly + the audit log.

Then, as requested, the automation in full image mode + the two audit logs for the automation.

I hope you get a little more insight.

As I said, the service request arrives but only sequentially. That means, when the first task is completed, then the first service request and when the second task is completed, then the second service request.

I would like to receive all service requests that are clicked in the form when the first two tasks are completed.

Best regards

[Bill Sheboy]

After reviewing your rules and audit logs, they confirm my original post: the smart values condition is incorrect to detect the status of the subtasks, and that data is not available to perform the condition:

• For smart values such as parent and subtasks, all of the data is not logged at one time.  If rules did that, you could imagine a situation where a single issue pulls in the data from thousands of issues!  And so the condition in your rule #3 cannot work
• And as I first noted: iterating a list to check the status values produces a list of values...and that cannot match a single value

And so that second condition in rule #3 could use the Related Issues Condition, assuming the trigger issue is a Sub-task:

• related issues condition:
  • related issues: JQL issues
  • related issues JQL: parent = {{triggerIssue.parent.key}} AND status != Done
  • condition: are not present

This inverts the test so the rule does not proceed if there are any incomplete subtasks.

Next, I note in your rules the subtasks are named "Sub-Task", which is different than the default issue type named "Sub-task".  This means someone likely added additional issue types.  I recommend carefully reviewing if there are multiple issue types with very similar names to prevent problems.

Next, in your rule #1 with the Issue Created trigger, that could have timing problems, leading to errors or incorrect condition results.  I recommend always adding the Re-fetch Issue action immediately after the Issue Created trigger.  This will slow the rule a bit and reload the data before the rule proceeds.

Finally, this is quite a complex scenario, and so asking the Atlassian Community for help seems to be asking a lot.  I recommend working with your Jira Site Admin on such cases, or working with a consulting / implementation partner to help.

[Marc - Devoteam]

HI @Dimitrios Kouroumichakis 

I second @Bill Sheboy 

Are their multiple branches or just one, but do remember branches run in parallel to the rest of the rule. So it can be that your rule is acting on a condition/action in a rule, when the branch in your rule is still active.