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: * Case is received by a service agent in JSM. * Agent is unable to resolve the defect so a case needs to be sent to our Engineering team for a fix. * 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. * Engineering team moves the child case through dev, test, QA, and a fix is created. * 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

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.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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:

Case is received by a service agent in JSM.
Agent is unable to resolve the defect so a case needs to be sent to our Engineering team for a fix.
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.
Engineering team moves the child case through dev, test, QA, and a fix is created.
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

Accepted answers

Mark Segall

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.

All comments

Mark Segall

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

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

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.

Screenshot 2022-04-18 102602.png

Thanks,

Russ

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

Mark Segall

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

Issue transitions to Done
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?

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud

automation

jira-service-management-cloud