Need Help with Jira Automation: Incrementing a Counter for Sub-tasks

Ahmed Saci October 31, 2023

Hello Atlassian Community,

I'm encountering an issue with Jira Automation. My goal is that each time a new sub-task is created under a specific ticket (or task), it should be given a unique identifier such as OP-1, OP-2, etc. However, it's vital that this counter be specific to each parent ticket.

For instance, if I create a sub-task under Task A, it should be labeled as OP-1, the next one as OP-2, and so on. Now, if I then create a sub-task under a different Task B, it should also start with OP-1, not continue incrementing from Task A.

Here's what I've tried so far:

Trigger: When a ticket is created.
Condition: The ticket type is "Operation" (or my specific sub-task type).
Action:
Set a ticket property Operation_ID for the parent ticket by incrementing its current value.
Update the sub-task fields with the new Operation_ID value from the parent ticket.
However, the results aren't as expected. The sub-tasks either get a blank value or the counter doesn't increment correctly.

Could someone guide me on how to achieve this, or if there's a better approach to handle this scenario?

Thank you in advance!

2 answers

0 votes
Trudy Claspill
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
October 31, 2023

Hello @Ahmed Saci 

Please show us screen images of your Automation Rule and the output in the Audit Log for its execution.

If you are updating the parent issue and then trying to reference a value from that issue to update your subtask, then the problem may be that you need a Refetch action after updating the parent issue to get the current information for that issue.

It is also possible that depending on the structure of your rule steps are running in parallel rather than sequentially, so the parent issue may not yet have been updated at the time when you want to update the subtask.

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 31, 2023

Hi @Ahmed Saci 

Adding to Trudy's answer:

A key thing for how you solve this is how subtasks are added: manually, in rules, or both.  Seeing your rule and knowing that will help guide any suggestions.

In the meantime: what problem are you trying to solve by having a unique identifier for each subtask, relative to their parent?  That is, "why" do this?  Knowing that will help the community perhaps suggest additional solution approaches.

Kind regards,
Bill

Ahmed Saci November 1, 2023

Hello everyone @Bill Sheboy @Trudy Claspill @Matthew , and thank you for your insights.

First, I'll be sharing my automation rule with you shortly to provide a clearer understanding of my current configuration.

automation field ID increment.png

Automation Rule Steps:

1-Trigger: Ticket Created
The rule is executed when a ticket is created. This trigger does not require any configuration.

2-Condition: Ticket Field Condition

Check if a ticket field meets certain criteria.
Field: Ticket Type
Condition: is equal to
Value: subtask
3-Action: Define the Entity's Property

Advanced action used to set key-value data pairs for use by other rules, automations, or apps.
Entity Type: Ticket
(Set a property on the ticket that triggered this rule, or on the current ticket regarding a related ticket branch.)
Property Key: Operation_ID
Property Value: "{{#increment}}{{issue.parent.properties.Operation_ID}}{{/}}"
4-Action: Modify the Ticket

Define values for fields concerning the ticket.
Fields to define:
Operation Number: "OP-{{issue.parent.properties.Operation_ID}}"
5-Action: Modify the Ticket

Define values for fields concerning the ticket.
Fields to define:
Summary: Work Card: "{{issue.parent.key}} | OP- {{issue.parent.properties.Operation_ID}} | {{issue.summary}}"

To address Bill's question: the sub-tasks are added manually. The primary reason I want each sub-task to have a unique identifier such as OP-1, OP-2, etc., is for operational efficiency within my company. These identifiers serve as a crucial tool for distinguishing between different operations tied to a task. It's essential for our workflows and processes.

The incrementation should be tied specifically to the parent ticket, i.e., the main task. For clarity, if there's another separate main task and I create sub-tasks under it, I expect the same pattern to emerge with identifiers like OP-1, OP-2, and so on, starting from OP-1 again. It shouldn't continue the incrementation from a different task's sub-tasks. This distinction is vital for our operational clarity.

Thank you for taking the time to assist. Your expertise is highly valued, and I look forward to your suggestions.

 

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 1, 2023

First thing: when using the Issue Created trigger, I recommend always following that with the Re-fetch Issue action.  This trigger can fire so quickly that the data is not available for later rule processing, and the re-fetch will slow the rule by about one second and reload the data before proceeding.

 

You rule is using an entity property for the "counter", stored on the parent of the trigger issue.  When you want to increment that value, the rule must first branch to the parent issue, to perform the edit.  Otherwise you are adding that property to the trigger issue.

 

Next, after you increment the property, there are two things to consider:

  1. When a rule makes a change to an issue (particularly the trigger issues), those changes are not yet visible to the rule...they are only stored in the Cloud.  Adding a Re-fetch Issue action will reload the data before proceeding after an edit.
  2. When you edit the trigger issue to add the parent's entity property, I do not know if that is visible.  Please test to confirm it is.  If not, you may use a work-around by loading the parent issue into the Lookup Issues action to access the property.
Ahmed Saci November 2, 2023

Hi @Bill Sheboy 

Thank you for your prompt response and detailed instructions

I followed the instructions provided, but it's still not incrementing correctly. Every time I create a sub-task, it always sets the value as OP-1.

increment ID operation 4.png

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 2, 2023

The re-fetch issue action must be outside and after the branch to reload the data for the trigger issue.

Ahmed Saci November 3, 2023

Hi @Bill Sheboy 

No its not Work . in the same issue Parent if I create a sub-task A the value  OP-1  and a subtask B it always sets the value as OP-1

increment ID operation 5.png

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 3, 2023

I just noticed an error in your increment, smart value expression...When you increment the value, the branch is already to the parent.  And so the smart value should be:

{{#increment}}{{issue.properties.Operation_ID}}{{/}}

or more simply:

{{issue.properties.Operation_ID.asNumber.plus(1)}}

0 votes
Matthew October 31, 2023

I would trigger every time a subtask is created and count the number of subtask. I don't know if PO-{{parent.subtasks.size}} would work as the counter or if you have to branch off the parent and set a variable to get {{issue.subtasks.size}}. That will always return the number of subtask and you just need to ask the prefix to it.  That is how I would approach the problem in theory. 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events