Desk Ticket and Cloned Ticket Workflow Status Mapping

Question

Hi,

I am trying to build an automation where I want the cloned tickets (which will be going into separate project teams that will be working on their tasks) to communicate with the original desk ticket. This is how I want the status to reflect (attaching the whole workflow, and level 1 vs level 2 status reflections for each project team, which is prod squad, penbi team, and devops team):

Also, when there are multiple clone tickets within the desk ticket, I want the desk ticket to resolve/close when all the sub-tickets or cloned tickets are resolved/closed.

I'm also a little conflicted as to how I should account for the status mapping when there are multiple clone tickets. Are there any existing examples from which I can take inspiration form to manage this? or any suggestions?

James Gamble · Accepted Answer

Hola Kinza,

I think the main thing to avoid is having the desk ticket simply copy the status of the most recently changed cloned ticket. That works when there's only one clone, but once several teams are working in parallel, the desk ticket needs to reflect the overall state of all of them.

Based on the mappings in your screenshots, I'd treat the desk ticket as a rollup. If every linked clone is either Done or Canceled, the desk ticket can be moved to Done. If any active clone is blocked or On Hold, the desk ticket should probably move to hold. If any clone is actively being worked, reviewed, tested, or reworked, keep the desk ticket in In Progress. I'd only move it to Ready for Review once all remaining active clones have reached the acceptance stage. Until then, Backlog and To Do clones can keep it in Level 2 Review.

You can do this with a multi-project or global automation rule. The rule triggers when one of the cloned tickets changes status, then follows the link back to the original desk ticket, and checks all other linked clones before deciding what the desk ticket should do. Here's some more information for reference.

For the closing behavior, the important check is that all of the linked L2 tickets are in a completed status before the desk ticket closes. Atlassian has a similar example you can adapt here.

I'd also make sure the rule only looks at the specific link type used for these clones; an unrelated linked issue could affect the rollup. Another edge case to decide up front is what should happen when some clones are done, and others are canceled. In most cases, I'd still close the desk ticket as Done unless every clone was canceled.

Thanks,

James