questions about automation implementation

[Angel Salazar]

Hi guys, can you help me a little with the logic or structure of an automation rule that meets the following requirements:

- When creating a story, 7 subtasks must be created.
- Each of these subtasks must have the start date (custom field) and due date (native field) fields among their fields. (This is already done.)
- The start date field must be a non-editable field.
- The due date of subtask 1 must be the start date of subtask 2, and so on until the last subtask.

Example: If the due date of subtask 1 is 01/08/25, that same date must be the start date of subtask 2. If subtask 2 has a due date of 07/08/25, that date must be the start date of subtask 3, and so on in that order.

- If the customer changes the due date of a subtask, the start date of the next subtask is updated.

Example: Taking the previous example as a reference, where the due date for subtask 1 is 01/08/25 and the start date for subtask 2 takes the same value, if the client decides to change and extend the due date for subtask 1 by one week to 08/08/25, the start date for subtask 2 would be updated to this new value.

[Angel Salazar]

Hola @Bill Sheboy  @Trudy Claspill , Campeona de la comunidad lo que he hecho hasta el momento es lo siguiente en una instancia de prueba:

Crear primera regla que cuando se cree una incidencia y el tipo de incidencia es "historia" cree 3 sub tareas. Luego hice una rama para subtareas que en base al resumen de cada subtarea editara los campos fecha de vencimiento y fecha de inicio.

Estos valores me los sugirió la IA  de Atllasian Rovo. Me sugirió que a partir de la sub tarea 2 como fecha de inicio utilizara la sentencia {{createdIssues.get(0).dueDate}} para devolverme la fecha de vencimiento de la subtarea anterior  y la sentencia {{createdIssues.get(0).dueDate.plusDays(7)}} en fecha de vencimiento y para las siguientes sub tareas sería lo mismo pero incrementaría el valor del numero del "get".

Les muestro el error que me dió:

Creé también una segunda regla que es idéntica a la que me sugiere @Trudy Claspill, Campeona de la comunidad en su artículo que cuando cambien las fechas de vencimiento de una sub tarea actualicen las fechas de inicio de las sub tareas dependientes con el nuevo valor pero no ocurre nada en sus registros de auditoria

[Bill Sheboy]

Please carefully re-read what I posted and Trudy's article...

Trudy's article describes a scenario where a chain of work items are linked as "Blocked".  And so as one work item's dates are changed, the dependent one is updated.

The rule you show is not identical to that case: instead you are branching over all of the subtasks.  This is the case I noted would not work: either creating items as new or branching on the links is required.

As for that bot / AI-generated suggestion, it cannot work: it would require having the if / else condition block inside of branches, and that is not possible with automation rules.

[Bill Sheboy]

Hi @Angel Salazar 

Short answer: in my opinion, scenarios like this are quite difficult in Jira as it has limited built-in project-management features for cascading updates of a chain of work items.  It may be better to investigate marketplace addons to Jira for such features.

Assuming you are still interested in using automation rules...

What have you tried thus far to solve this need?

If you have a rule that is not working as expected, context is needed for the community to help.  Please post the following:

• what version of Jira are you using: Cloud, Server, or Data Center
• for Cloud, what type of project is this: company-managed, team-managed, JPD, etc.
• an image of your complete automation rule in a single image for continuity
• images of any relevant actions / conditions / branches
• an image of the audit log details showing the rule execution
• explain what is not working as expected and why you believe that to be the case

If you have not started a rule yet, I encourage you to try.  Successfully using automation rules requires learning and experimentation.  When one just asks the community to "tell me how to build this rule", it is unlikely your team will be able to maintain it over time as they will likely not understand it.

To help get you started on your rule...

• The scenario you describe is quite challenging as automation rules cannot loop / branch sequentially.  Thus a rule cannot loop over the subtasks you describe to perform cascading updates.  There are two exceptions which would allow this:
  • Create the subtask one at a time (with no branching) to allow referencing the prior one.  Although this will not handle the update cases.
  • Add work item linking (in one direction) between the subtasks, and use a recursive rule to make updates.  This approach is challenging as the service limits could halt the rule(s).
• You may be able to prevent manual updates of the Start Date field by not including it on views...but that may only work if there are controls in place to prevent someone from adding the field later
• Please see this information to learn more about automation rules: https://support.atlassian.com/cloud-automation/docs/jira-cloud-automation/

Kind regards,
Bill

[Trudy Claspill]

Hello @Angel Salazar 

I wrote an article on the topic of automatically updating dates on dependent tasks. You might find it helpful.

Updating dependent task's dates when predecessor task date changes 

[Trudy Claspill]

Hola @Angel Salazar ,

Respecto al error que recibes en tu primera regla:

"Hemos encontrado varios campos con el mismo nombre y tipo".

Esto indica que hay más de un campo llamado "Fecha de inicio" en tu instancia de Jira, y la regla no especifica cuál intentas usar. Al hacer clic en el botón "Elegir campos para configurar" en la acción "Editar", ¿apareció más de un campo llamado "Fecha de inicio"?

Lamentablemente, tu escenario no cumple con los requisitos de mi artículo, específicamente:

3. Esta solución se basa en el uso de la función nativa de vinculación de incidencias de Jira, donde el tipo de enlace utilizado tiene valores diferentes para la descripción externa y la interna.

Como tu escenario no cumple con este requisito, la solución de mi artículo no te funcionará.

Y la segunda regla que creaste no coincide exactamente con lo que documenté en mi artículo, ya que la de mi artículo usa una rama para incidencias vinculadas, mientras que la tuya intenta usar una rama para subtareas. La rama para subtareas no funcionará en la regla que creaste. Una rama para subtareas intentará iterar sobre las subtareas de la incidencia desencadenante. Dado que la incidencia desencadenante es en sí misma una subtarea, no puede tener subtareas secundarias.

Si va a confiar en el Resumen de la Subtarea para indicar el orden de las Subtareas, necesitará una estructura diferente para su regla a la que presenté en mi artículo.

---

Hello,

Regarding the error you're getting in your first rule:

"We have found several fields with the same name and type"

That indicates that there is more than one field named "Start date" in your Jira instance, and the rule is not clear about which one you are trying to use. When you clicked on the "Choose fields to set" button in the Edit action, did it list more than one field named "Start date"?

Unfortunately your scenario does not align with the requirements in my article, specifically:

3. This solution does rely on the use of the native Issue Linking feature of Jira where the link type used has different values for Outward Description and Inward Description.

Because your scenario does not meet that requirement, the solution from my article will not work for you.

And the second rule you created is not an exact match for what I documented in my article, because the one in my article uses a branch for Linked Issues, while yours is trying to use a branch for Subtasks. The branch for Subtasks will not work in the rule you created. A branch for Subtasks will try to iterate over the Subtasks of the trigger issue. Since the trigger issue is itself a Subtask it cannot have child Subtasks.

If you are going to rely on the Summary of the Subtask to indicate the order of the Subtasks, you would need a different structure for your rule than what I presented in my article.

Hi @Bill Sheboy @Trudy Claspill, Community Champion, what I've done so far is the following in a test instance:

Create a first rule so that when an issue is created and the issue type is "story," it creates three subtasks. Then I created a branch for subtasks that, based on the summary of each subtask, would edit the due date and start date fields.

These values were suggested to me by Atlassian Rovo's AI. It suggested that, starting with subtask 2, I use the {{createdIssues.get(0).dueDate}} statement as the start date to return the due date of the previous subtask, and the {{createdIssues.get(0).dueDate.plusDays(7)}} statement as the due date. For subsequent subtasks, it would be the same, but would increase the value of the "get" number.

Here's the error I got:

I also created a second rule that is identical to the one suggested by @Trudy Claspill, Community Champion in her article that when the due dates of a subtask change, the start dates of the dependent subtasks should be updated with the new value, but nothing happens in their audit logs.