Ticket Linking

Add option to set up a parent/child relationship between tickets.

Here are two example scenarios where it would be helpful:
• A large project for a single customer to allow us to track the individual tasks separately but still have them linked, so we can make sure we complete all tasks in the project before resolving it.
• A migration project where we need to track multiple customers from one service to another, so we can end cancel the service without missing any customers.

6 Likes

This is an excellent thought - this seems to be a gap in Syncro’s PSA. I struggle to deal with big projects - I can’t delegate various tasks inside of a big project ticket to multiple people unless I just make dozens of tickets.

I’d love to hear @Andy or others at Syncro on this kind of feature.

My gut would be if we were going to do this we’d probably make “project” objects instead and let you link tickets and invoices to that. I’m not sure doing just ticket linking would get folks where they’d want to be with a need like this.

2 Likes

Whatever direction you decided to go, it would be an improvement over no linking at all.

4 Likes

Well there could be a case made that major outages/issues could have an overarching parent ticket which would be assigned to higher level technicians to respond to the root cause with individual child tickets being handled by helpdesk with provided workarounds.

At the moment we currently have to merge in all newly created tickets to the initial support ticket which creates a very long list of notes that has to be checked for works/troubleshooting completed.

So it could probably be utilized outside of just project work.

We’ll I’m curious on this one specifically, would you rather link all these tickets together or bulk merge them? This use case feels like bulk merge might be a better option if we were to add it.

Well I suppose that would come down to ticket workflow and invoicing process.
In my personal opinion, linking tickets allows major incident tickets to seperate action plans and root causes seperately for higher level troubleshooting and disaster management whilst individual user tickets which would be linked are used by lower level technicians to deploy workarounds and keep track of affected users and their individual troubleshooting.
Bulk merge of tickets achieves a similar result, however your activity log and charge sheet are continuously added to and need to keep being summarised and invoiced to keep track of everything.

Yeah that’s a good point on the charge sheet stuff. I was more thinking of contract-based offices that lose internet and like 12 employees open tickets all at the same time (which is not helpful). I’m starting to think there are good use cases for each.

FWIW I like the ticket linking idea for other reasons as well.

1 Like

I have issues that affect multiple customers that are the same root cause sometimes. I can’t merge those together. I end up creating a “master” ticket in an internal customer (Morris Tech Team internal) and paste hyperlinks to all of the customers’ tickets that are related. It’s awkward.

1 Like

Yeah in those cases that’s 100% the primary use case for ticket linking. I was just saying merging probably makes more sense for one customer bulk opening tickets. I think both feature requests have their own designated use case, probably with some small overlap at times.

1 Like

Can you propose a framework that would allow you to link tickets together for different customers and then bill those customers appropriately?

For example, the recent zero-day Java exploit had me remoting into multiple clients’ servers to disable the Java runtime while waiting for the APC PowerChute patch to be released. I created a dozen individual tickets which admittedly was a pain, but if that had instead been one big ticket linked to all the customers, how would that look when it came time to bill?

Or are you just suggesting a “related” sort of link, like Amazon’s “Since you’re interested in this, you might also like…” I can see the utility of that – e.g. I solved the problem for one customer, then the link allows me to find other customers who need the same solution. You’d just have to figure out the appropriate amount of time finding the solution to allocate to each customer (i.e. I wouldn’t want to charge the first one 2 hours for R & D and just 15 min to each of the others for the actual implementation).