Use case
In many cases, it is critical that tasks are completed in a strict order. To ensure this, individual sub-tasks are scheduled to occur in a predefined sequence. Each sub-task cannot begin until the previous one has been completed. In addition, the is blocked by relationship enforces this order by preventing a subtask from starting until its prerequisite has been completed. The Execute sequence of actions provides precise control over task execution, making it easy to define dependencies and enforce sequential processing in a single step. In this use case, we will demonstrate the setup using a simplified development process by creating four subtasks, each scheduled one week apart and blocked from each other.
Prerequisite
To configure this use case correctly, make sure that the sub-task screen have two date fields: Start date and Planned end. Check that these are correctly configured as date fields.
⚒️ Configuration
Choose Execute sequence of actions as a post function.
First sub-task: Planning
To create the first task, add the Create issue post function as a JWT action. Select Single issue as the mode and Sub-task as the selected issue type. The summary of the first sub-task is "Planning".
Now add two different fields to set the Start date and End date. In the Start date field choose the dateTimeToString() function to set the date to the current date. For the Planned end choose the same function but add seven days (7*DAY).
%{dateTimeToString({system.currentDateTime} , "YYYY-MM-DD" , RUN_AS_LOCAL, RUN_AS_LANG)}
For the Planned end choose the same function but add seven days (7*DAY).
%{dateTimeToString({system.currentDateTime} + 7*DAY , "YYYY-MM-DD", RUN_AS_LOCAL, RUN_AS_LANG)}
As the final step in this post function, go to Additional options , select the issue key, and store it in the Temporary text 1 field.
Second sub-task: Specification
For the second sub-task, use the Copy button to duplicate the previous sub-task. Then, edit the new sub-task by changing the Summary to Specification.
In the next step, we configure the date fields by using the previously set temporary text field to reference the planned end date from the previous task. To achieve this, we need the issueKeysToIssueList() function because the fieldValue() function, which we use to reference our custom field, expects a list. However, since we only need a single value, we use the first() function.
Next, adjust the Start date by adding 7 * DAY and the End date by adding 14 * DAY, while leaving all other fields unchanged.
%{dateTimeToString(first(fieldValue({issue.cf12323}, issueKeysToIssueList(%{issue.temporaryText1}))) + 7*DAY , "YYYY-MM-DD" , RUN_AS_LOCAL, RUN_AS_LANG)}
%{dateTimeToString(first(fieldValue({issue.cf12323}, issueKeysToIssueList(%{issue.temporaryText1}))) + 14*DAY , "YYYY-MM-DD" , RUN_AS_LOCAL, RUN_AS_LANG)}
To create the correct dependencies, go to Issue links , select Add issue link , choose Is blocked by , and then use Select issues manually (parser expression) to reference the issue stored in Temporary text 1 by setting the expression to %{issue.temporaryText1} . The Temporary text 1 field is automatically overwritten when the next sub-task is created.
%{issue.temporaryText1}
Third sub-task: Implementation
For the third sub-task, use the copy button again to duplicate the previous sub-task. Then, edit the new sub-task by changing the Summary to "Implementation" and adjusting the Start date by adding 14 * DAY and the End date by adding 21 * DAY, leaving all other fields, including Issue links and Additional options, unchanged. The Temporary text 1 field is automatically overwritten when the next sub-task is created.
%{dateTimeToString(first(fieldValue({issue.cf12323}, issueKeysToIssueList(%{issue.temporaryText1}))) + 14*DAY , "YYYY-MM-DD" , RUN_AS_LOCAL, RUN_AS_LANG)}
%{dateTimeToString(first(fieldValue({issue.cf12323}, issueKeysToIssueList(%{issue.temporaryText1}))) + 21*DAY , "YYYY-MM-DD" , RUN_AS_LOCAL, RUN_AS_LANG)}
Fourth sub-task: Testing
For the fourth sub-task, again use the copy button to duplicate the previous sub-task. Then, edit the new sub-task by adjusting the Start date to 21 * DAY and the End date to 28 * DAY, leaving all other fields, including Issue links and Additional options, unchanged.
%{dateTimeToString(first(fieldValue({issue.cf12323}, issueKeysToIssueList(%{issue.temporaryText1}))) + 21*DAY , "YYYY-MM-DD" , RUN_AS_LOCAL, RUN_AS_LANG)}
%{dateTimeToString(first(fieldValue({issue.cf12323}, issueKeysToIssueList(%{issue.temporaryText1}))) + 28*DAY , "YYYY-MM-DD" , RUN_AS_LOCAL, RUN_AS_LANG)}
Following the same concept, any number of issues can be created while maintaining the defined sequence and dependencies.
In addition, a condition can be added to the sub-task workflow to ensure that a sub-task cannot be moved to Done until the sub-tasks it is blocking have also reached Done.
📚 Related Examples
| Use case | Workflow function | Parser functions |
|---|---|---|
| Automating sub-task creation with controlled sequence | ||
| Creating IT tasks and adding watchers for onboarding |