Automation ideas for Parent-Child cases

[Russ White]

I am looking for some help or ideas on configuring an automation rule that will update a parent case when a subcase status has changed. We currently just get the Jira notification emails, but there are always too many of those and we don't catch the status updates a lot of times.

Our workflow goes like this:

1. Case is received by a service agent in JSM.
2. Agent is unable to resolve the defect so a case needs to be sent to our Engineering team for a fix. 
3. We use a recipe in Elements Copy and Sync to copy the details of the support case (parent) to a new Engineering case (child) in Jira Software.
4. Engineering team moves the child case through dev, test, QA, and a fix is created. 
5. Child case is moved to Done status and a standard Jira notification email is sent to agents and watchers.

****This is where I would like an automation for a update on the parent case that the child case has been marked as done.****

I would like for the agent to be updated somehow that the child case has closed or update the parent case status to the 'Waiting for Support' status so that it is more visible in our queues.

Thanks in advance for any advice!

-Russ

[Mark Segall · Accepted solution]

Hi @Russ White - You could definitely handle this with automation:

• TRIGGER: Issue transitioned
  • To: Closed
• BRANCH: Parent
  • CONDITION: Status = x (make sure that the parent issue is in a status that can transition to Waiting for Support)
  • ACTION: Transition Issue
    • Waiting for Support
  • ACTION (Optional):  Send Email to Assignee

I made the Send email action optional because if the users are already feeling like they're getting Jira spam, another email is not going to help.  Transitioning the issue and living out of the queue is definitely the best course.

[Filipi Lima]

This is the way I would go as well!

I would also make sure to filter the automation for the issue type(s) associated to your engineering cases.

Keep in mind this solution would need some tweaking if you ever needed to create multiple sub-tasks for a given Support Case.

[Russ White]

Hi @Mark Segall ,

Thank you for your suggestion. I have been testing this out in my sandbox, but I'm not getting the rule to trigger for some reason. One clarification on my source issue. We are actually using 'Linked Issue' instead of a true parent-child case relationship. I noticed that while creating the rule you suggested and have tested with both 'Parent' as well as 'Linked Issue' Neither of these conditions seems to do the trick. Here is a snapshot of what my rule looks like currently.

I have confirmed that my source/parent issue is in a status that can transition to Waiting for Support.

Thanks,

Russ

[Mark Segall]

Hi Russ - By reading through your rule, it appears that it takes the following actions:

1. Issue transitions to Done
2. branches into all issues that meet the criteria of PROJECT = Sandbox AND "blocks", "blocked by", "clones", "cloned by", and "relates to"
   1. For each linked issue, checks if Done or Declined
   2. Transitions each of the linked issues that are Done or Declined to Waiting for Support
   3. Sends an email to the assignee of that issue

Based upon your needs, my initial thoughts are:

• If you're simulating parent child through links, this is fine, but you probably have too many link types. 
  • If you're triggering off of your "child", you want the branch to focus on "Blocks" or "Clones". 
  • If you're triggering off your parent, you want the branch to focus on "Blocked By" or "Cloned By"
• I'm assuming that since you have multiple teams this is expected to be a cross-project rule.  That means your project scope (located under Rule Details) needs to be set to either multiple projects or Global
• The branch condition seems off to me.  You're wanting to transition Done/Declined issues to Waiting for Support?

[Russ White]

Hi @Mark Segall ,

You've described the rule correctly. 

• If you're simulating parent child through links, this is fine, but you probably have too many link types.
  • [RW] - you are correct. I've narrowed this down to "Blocks" or "Clones" as I want the child/linked issue to trigger this rule.
• I'm assuming that since you have multiple teams this is expected to be a cross-project rule.  That means your project scope (located under Rule Details) needs to be set to either multiple projects or Global
  • [RW] - I think this might be what is holding me up. I just have this rule enabled for the sandbox project that the moment, which would be my parent/source project of the case. I am assuming that I would need to include all of the projects that I am syncing to (~20+ different projects) in order for this to fully work or else put this at the global level as you suggested. If I have this triggered at the global level, am I correct in assuming that the rule will just not trigger or transition the cases if those projects are not using the Waiting for Support status?
• The branch condition seems off to me.  You're wanting to transition Done/Declined issues to Waiting for Support?
  • [RW] - I can see where this might seem off, but our process is that our Support team be the communication to our customers. I am currently linking a case to our Engineering team to work on defects or product enhancements. Our customer's do not have full vision into those cases so it is up to the Support team to notify the customer when a case closes or more information is needed; therefore, I want this rule to update the originating case to notify the Support team to take action. 

[Mark Segall]

If I have this triggered at the global level, am I correct in assuming that the rule will just not trigger or transition the cases if those projects are not using the Waiting for Support status?

You probably want to think about additional conditions if you're going global scope.  This will trigger on every issue that transitions to Done so you may want to add an issue type/request type condition to further refine it.  Without refining, you'd also likely get peppered with errors for the situations where the issue is Done, but cannot transition to Waiting for Support.  Lastly, even if you're cool with the errors and simply suppress them, you'll have to contend with the potential for heavy processing, and throttling errors, depending upon how often linking is used in your environment and overall activity level. 

[Russ White]

Yeah that's what I was worried about. I will think on this a bit more, but I appreciate your responses and helping through this. Thanks @Mark Segall 

[Alex Koxaras _Relational_]

Hi @Russ White 

As far as I know you can achieve what you want via the Elements Copy & Sync. If you have created a recipe for copying an issue from the JSM to a JSW project, then on that specific recipe you can state to what status you can update your source (JSM) issue, if the target (child) issue transitions to a specific status:

Let me know if that helps!

Alex

[Russ White]

Hi @Alex Koxaras _Relational_ 

Thanks for your input on this as well. Using Elements Copy & Sync might also be a great way to go with this; however, we are not using a single target project where we would Copy and Sync from the source to the target project. Some of the target projects will be team-managed projects and the workflows may vary. When trying to set up the workflow as you suggested that came to my attention and I realized that I would have to update the workflow each time if we added a new project/workflow.

Does using a team-managed project have any bearing on setting this up?

Thank you,

Russ

[Julien Peyrade _ Elements]

Hello @Russ White 

Team-managed projects' workflows cannot be synchronised by Elements Copy & Sync, as Jira does not use the same workflow system as regular projects, so the add-on won't be able to help you in that case.

However, for other cases, the proper way to set up your Jira would be to use the same workflow for all your engineering projects, as it makes sense they would use the same statuses. This way, you would only need to set up your Copy & Sync recipe just once for the "engineering workflow", and each new engineering project would use the same workflow, so you wouldn't need to update your Copy & Sync recipe for the synchronisation to work.

I hope this helps.

Julien

[Russ White]

Hi @Julien Peyrade _ Elements 

Thanks for your input as well. Our engineering projects do use the same workflows so I may look into your suggested workflow idea; however, we also have JSW team-managed projects that are run by our implementation teams. We have a process in place where we do have to create linked cases using Copy & Sync to those projects as well. So given what you've mentioned above, we may have to think about how best to handle those situations too.

I am still trying to figure out our next steps at the moment. In testing, I'm not able to get the suggestions above from, Mark Segall, to work just yet. I believe it's due to issues in my conditions. I'm trying to work through that right now.

I will update this thread again once I have my solution in place.

-Russ