Automation rules from Issue-type Incident workflow and Sub-types associated

[Vivian.HOAREAU]

Dear

Currently, I try to solve a request from user concerning the automation rules from Issue-type et sub-type associated for 2 requests below : Request 1 is done, but I have a problem on Request 2.

For your information on workflow, after RAISED, the status go to TREATING, then RESOLVED = point -B-

From Incident, I created an automation Rule to create a Data Issue

• If an Incident is raised (so status is 'Raised') and a 'Data issue' is linked to it, then automatically change the Incident status to 'Treating' if the status is still 'Raised' => Already Done, works well ! point -A-
• If all 'Data issues' linked to the Incident are Resolved, then automatically change the Incident status to 'Resolved' if the status is still 'Treating'. point -C-

If you have an idea for my request 2, thank in advance

- A-

- B -

- C -

C

[Ste Wright · Accepted solution]

Hi @Vivian.HOAREAU 

Are the Data Requests sub-tasks of the Incident, or related to the Incident via linked issues? Both appear to be present in -C-

-----------------

If I'm reading the requirement correctly, you need for -A-

• If an Incident is in the status "Raised"
• And a Data Request is linked to it (link type or sub-task)
• Then change the status of the Incident to "Treating"

And then for -C-

• If all related Data Requests linked to an Incident are resolved
• Change the Incident status to Resolved

Below I've created rules for -A- and -C- based on either link type or sub-task. If you have any questions about the instructions, please feel free to add a comment below!

-----------------

-A- Link Type

If Data Requests / Incidents are linked:

1. Trigger: Issue Linked - set link type to the type which applies to Incidents / Data Requests. For example Blockers (Data Request blocks Incident)
2. Condition: Issue Fields Condition - if Issue Type (field) equals (condition) Data Request (value)
3. Branch: For related issue, choose Destination Issue
4. Condition: JQL Condition - issuetype = Incident and status = Raised
5. Action: Transition Issue: Treating (destination status)

The trigger Issue Linked assumes the source issue is where the action should take place, rather than the destination. I assumed that Data Request is the source issue (eg. Data Request blocks Incident), hence the need to clarify the destination issue in step 3.

-A- Sub-Task

If Data Requests are sub-tasks below Incidents:

1. Trigger: Issue Created
2. Condition: Issue Fields Condition - if Issue Type (field) equals (condition) Data Request (value)
3. Branch: For related issue, choose Parent
4. Condition: JQL Condition - issuetype = Incident and status = Raised
5. Action: Transition Issue: Treating (destination status)

-----------------

-C- Link Type

To then close the Incident, if Data Requests are linked, using the same example above (Data Request blocks Incident):

1. Trigger: Issue Transitioned: To status Done
2. Condition: Issue Fields Condition - if Issue Type (field) equals (condition) Data Request (Value)
3. Branch: For related issue, choose Linked Issues - with a link type of "blocks"
4. Condition: JQL Condition - issuetype = Incident and status = Treating
5. Condition: Related Issues Condition - if Linked Issues (related issues) of "is blocked by" (link type) none match specified JQL (condition) - JQL = issuetype = Data Request and status != Done
6. Action: Transition Issue: Done (destination status)

The way this rule works, is the Trigger is a Data Request - the Branch in (3) then moves the action to any linked issue related to the trigger issue with a type "blocks" - like Incidents.

The condition in (4) then verifies the issue type (Incidents) and status to take action against. 

In (5), the rule then checks the opposite way, that all issues linked to the Incident via "is blocked by" are resolved, by checking no related Data Requests are open. The condition "none match specified JQL" allow other issue types to be blocking the Incident but not impact the automation rule.

-C- Sub-Tasks

Likewise, to close the Incident if Data Requests are sub-tasks:

1. Trigger: Issue Transitioned: To status Done
2. Condition: Issue Fields Condition - if Issue Type (field) equals (condition) Data Request (value)
3. Branch: For related issue, choose Parent
4. Condition: JQL Condition - issuetype = Incident and status = Treating
5. Condition: Related Issues Condition - if Sub-tasks (related issues) none match specified JQL (condition) - JQL = issuetype = Data Request and status != Done
6. Action: Transition Issue: Done (destination status)

The Branch in (3) moves the action from the Data Request sub-task to the Incident parent; (4) then verifies this is just for Incidents in the right status, before (5) checks that all other Data Request children are also in Done.

-----------------

All the statuses, JQL values, etc can be refined depending on your specific user cases - for example, the Actions could be extended if you need to set resolution as well as status during closure.

The target here was to fully automate the process without the need for manual triggers.

Let me know if this all makes sense and if you have any questions, please leave a comment below!

Ste

[Vivian.HOAREAU]

Thanks a lot Stephen for your answer.

I tried again and again this solution by respecting the order for "C-Link type" => impossible to put from "TREATING" to "RESOLVED"

I executed each queries requested on your solution with validation JQL (it"s ok) but the Status change still not working !

I always try to find the solution this week.

[Ste Wright]

Hi @Vivian.HOAREAU 

I assume "Treating" and "Resolved" are two statuses in the Incident Workflow? Is this where the error is coming from?

Is there a status transition between these two? The relationship has to exist for automation to function.

Perhaps a screenshot of the workflow for Incidents would be useful here, so I can tweak the rule specifically for your use-case :)

Ste

[Vivian.HOAREAU]

Yes, please have a look on picture attached below

No other transition between TREATING and RESOLVED

+ attached WF incident

Regards

vivian

[Vivian.HOAREAU]

[Ste Wright]

Hi @Vivian.HOAREAU 

First thing to check - on the rule itself, the Trigger states when issue transitioned FROM Done, Closed.

This should be TO as you're closing the issues, not reopening them.

I'd fix this first and see if it works.

---------------

If this doesn't solve the issue...

Are there any properties required to move an Incident from "Treating" to "Resolved"? For example is a resolution required? Or does it require a specific project role?

Ste

[Vivian.HOAREAU]

Hi Stephen

I changed from FROM to TO, same thing.

There is not properties required between TREATING and RESOLVED

I tested just a simple automation between Treating and Resolved and it's work.

the error finds in the Blocks  "Branch rule" on "Issue Linked". I tried with "BLOCK", "PARENT", etc.., I have an error each time : "No related issues could be found."

I will try to work on this part with others condition

Thanks

Vivian

[Ste Wright]

Hi @Vivian.HOAREAU 

Did you manage to get these rules working?

For the above comment, one thing you could try is:

1. Go to the Branch in -C- Link Type
2. Remove the check from the checkbox "Only include issues that have changed since the last time this rule executed"

^ See if results are now found from the Branch.

I built the rules in our environment and they worked - so hopefully you have been able to replicate this functionality and locate why Treating could not transition to Resolved! :)

Let us know if these are still not functioning as expected!

Ste

[Vivian.HOAREAU]

I Stephen

After some tests, I found my solution and it's working well (image attached)

Best regards

Vivian

[Ste Wright]

Hi @Vivian.HOAREAU 

Awesome! Glad it now works!

If this answer helped to find the solution, could you press "Accept Answer" at the top? 

This will help other users who locate this question know this thread will help!

Ste