Multiple jira issues creation through Automation

[srikanth u]

Dear Team,

We started to use extensively Automation feature in Jira (which is an excellent functionality), but currently we are facing a problem.

- We have a Jira project under that we do have multiple boards, each board specific to each team (UI, Backend, Backend 2 etc...).

- When a User Story created by the Product Owner, Engineering team will slice down the story into multiple Tasks (specific to their team) which are more technical in nature.

- Now I want to create these tasks automatically (worth to mention we do have more than 3-4 or more tasks per team).

Currently I have implemented this way, but with this only one task can be created per team when the respective custom field set to Yes.

This is how that I have implemented currently.

1). created a custom field "UI Task Needed" with the options "Yes/No".

2). Select the Story where team level tasks need to be created.

3). When the "UI Task Needed" set to Yes, a new Task will be created automatically and linked to the parent Story.

The same thing done for other teams based on the custom fields "BE Task Needed?" etc...

Any idea how we can multiple tasks to a team (Tasks will be evolved when the team slicing the Story further).

Thanks!

Srikanth.

[Bill Sheboy]

Hi @srikanth u 

I am unclear what the problem is you are encountering.  Would you please post an image of your current rule and describe what part does not work as you expect?  Thanks!

Automation rules may have up to 60 components; if you need to add multiple tasks based on those custom fields, you could use either if/else or advanced branching to help.  Your limit would be the maximum number of components.

If I am misunderstanding your use case, would you please explain what is preventing adding multiple tasks?

Kind regards,
Bill

[srikanth u]

Hi @Bill Sheboy Thanks for your quick reply.

Here are the Screenshots.

1. Creating a new Task when the Flag status set to Yes .

For eg: when UI Task Needed = Yes, a new Task will be created and add it to the Parent issue based on the above Automation rule.

Until now there is no issue as we are able to create a new Task after setting "UI Task Needed" = Yes, now the challenge for us is while if team wants to create another UI Task under the same parent we don't have an option (The one workaround is changing back "UI Task Needed?" to NO and then to "Yes" which is a bad solution and not a viable solution too!".

[Bill Sheboy]

Thanks for that information, and you are correct: you would need to toggle that custom field to create another task of that type.

How often you do need multiple tasks of the same type? 

• If it is infrequent, consider doing this manually rather than changing the automation
• If it is frequently, consider using a numeric custom field instead, such as "Number of UI Tasks Needed", and build the number based on the value using an advanced branch.

One more thing I noted, where you indicted "create another UI Task under the same parent".  You appear to be using just standard types (story and task) and so the task is not "under" any parent.  Is that what you intended?

[srikanth u]

Thanks again Bill, we wanted to do it frequently, given that Product Mgrs write down the User Stories and the Technical Teams (Scrum Teams - UI/ Backend/Adaptor/UX teams) have multiple Tasks to achieve the Acceptance Criteria.

More importantly the # Tasks are dynamic and used to vary from Story to Story.

One workaround that I found is "After creating the new Task again I am resetting back the custom field "UI Task Needed?" to NO, so that team can set it as Yes as and when needed (of course even this is a right approach, but a a workaround I feel for now, before I figure out the correct approach.

Once again Thanks Bill.

[Bill Sheboy]

With a dynamic number of tasks, it may be simpler to:

• create a manually triggered rule for each type
• allow team members to select/run the rule from the story, as often as needed, by type

That would eliminate the need for the custom fields and the resetting of the values.