Skip to main content

We’re looking to automate the creation of a “Repair Request” ticket after the resolution of an “Issue” ticket and need to link a singular asset between the two. Our current broken device workflow is that we have spare devices at each school that, when a staff member/student brings in a broken device, are checked out and become the user’s new primary device. In this case, we have our “Issue” ticket being created and resolved when the student/staff member gets their new device from the spares, but we need a “Repair Request” to then be created and assigned to our repair team since the device is still broken, but the original “Issue” is resolved. We have tags created to designate these ticket types, a basic ticket template, and a rule that already automatically fires the creation. However, I can’t figure out a way to link the original asset from the original “Issue” ticket to the new “Repair Request.” Is there any way this is currently possible?

@CGravitt 380201d ecasd Thank you for submitting your question to our Community. 

I think you could use a ticket template or subtickets to link everything together. 

Tagging some of our Community Regulars: @bclark @Cozmo03 @jclark16 @SMillsTVSD @akorkishko @nathaniel_lindley any ideas or thoughts here? 


Looking through the ticket template settings, it only looks like I can pre-select an asset but can’t automatically select the asset that was on the ticket that triggered the template tickets creation unless I’m missing something. We also aren’t looking to do it through subtickets as we are viewing it as two completely separate instances with the main issue of the student/staff member needing a new device being immediately satisfied. This leaves us no real reason to keep that ticket open, but we wouldn’t be able to close it with the subticket of “repair” still open. This would leave a ton of open issue tickets within the system that would technically have already been resolved and create unnecessary clutter. Please let me know any ideas any of you may have.


The only way I could think to do it is with an API call. That could read the open ticket, parse the info you want, and open a new one.

It might be easier to keep the original ticket open as the repair ticket, since that has a damaged device attached already, and create a new ticket (from a template probably) and attach the replacement device to that ticket?


@bclark I like the idea of keeping the original ticket and then using a template for the device in need of repair. 


@bclark @Kathryn Carter That would certainly work, but it still has the same problem of us wanting to automatically add the device to the new ticket. It’s just taking what we’d already be doing and flipping the order that the tickets are made.


To clarify, the damaged device you attach to both tickets?  In which case you’re right you’d be in the same spot.

 

Or the damaged device gets one ticket and the replacement device is attached on the other? (going back to my suggestion)


re-reading what you wrote in the OP I think I would suggest this: 

Device is damaged. Taken for repair. That ticket is used to process the repairs. 

A second ticket is created that references the first. “Replacement device for computer damaged in Ticket 123456)

And maybe a comment back in the first ticket that “device was replaced on ticket 123457”


To answer your question, yes, the device would be attached to the original ticket that was broken that we would label with an “Incident” tag, and then would also be attached to the second tagged as a “Repair Request”. I do like your suggestion, but I think it would alter our current workflow process too much for it to work for us.


Is the replacement device attached to a ticket?


It wouldn’t need to be, it would just be checked out to the user.


Maybe reverse the order of your parent/child tickets?

Repair ticket becomes the parent one so that it can remain open until your Hardware team (or whomever) fixes it. The replacement one becomes the child ticket and that part can be resolved? Though that doesn’t solve the part of auto adding a device.


I’ll have to test the process of that and bring it to the rest of the team, but maybe that could work.


Thanks @bclark for jumping in on this one. @CGravitt 380201d ecasd let us know how it goes!! 😄


It looks like we’re going to go for a more manual process in the meantime as we have had a fairly quick rollout time. We’re going to assign the ticket to a “Repair Team”, send that device to our repair shop, and the team will close the ticket upon receiving and open a new one through a template we’ve made. We’ll look into building further automation as we start to use the system more and improve on the base we’ve come up with. I’ll be sure to add on to this post if we end up using any of the scenarios we’ve talked about!


@CGravitt 380201d ecasd Thanks for giving us an update! 😄


Reply