For our service requests and some incidents, we used to spawn off a collection of child tickets for the tasks for items such as new employees (add to AD, add to maps, add to staff directory, etc), and those could be assigned to people.
I'm aware of the functionality of tasks in Freshservice, but it doesn't quite meet the mark because tasks do not show anywhere except the dashboard and the calendar, and we want them to be in their ticket queue instead.
Can we get an update on this?
We shipped a feature few months back, where you can add other additional items that your customers may ask for at the time of raising a service request. This eliminates the need for your customers to create multiple requests for different service items.
You can choose to create Child Tickets for these additional items or have all the items in a single ticket.
You can read about this feature in detail here.
Does that address your concern?
can you please elaborate on what you have asked. Perhaps, an example will help.
As you mentioned to Reese that she can enable to create child tickets from the SR which I'm already implementing in my business case but the tickets created in parllel once submitting the SR. My needs is to have dependent SRs for example:
If possible could we add the functionality to "hide" additional SR's in the service Catalog. Due to the inability to dynamically create "Child Tickets" as needed on SR's I have added the additional Child SR's into my catalog. However these additional SR's are only practical and useful in conjunction with the original parent ticket. Also due to the large amount of additional SR's that my environment needs it has caused the Service Catalog to become flooded with unusable additional SR's.
I would like to see either this functionality added or the ability to create dynamic child tickets per SR. I see a lot of potential with the service request. Please finish this section.
@Joseph, that doesn't quite fit the need that we have. Our process does not involve the customers, but is for creating tickets to disperse to other help agents. Here is an example scenario that happens almost daily for us:
We get a new employee notification from HR. That goes to our supervisor who then creates 7 child tickets for each task to be assigned to various help center staff. This is currently done by going one at a time and spawning a child ticket from that original request, choosing copy ticket details, renaming and recategorizing for the given task, and then assigning it.
As you can imagine that becomes a bit cumbersome, especially for our poor person who used to have it automated when we were using BMC Track-it.
thanks for providing detailed use case for your needs.
@Rehab - I'll be sure to add this to the long term roadmap. Based on interest from customers for this enhancement, we will prioritize it. I will be sure to keep you posted when we begin work on this.
@Jacob - I understand your requirement, will keep you posted when we start working on it.
@Reese - Let me see if I have understood your requirement correctly.
1. HR sends a notification/email to the helpdesk regarding a 'New employee Hire'.
2. Helpdesk supervisor creates 7 child tickets manually copying the details from the primary tickets to the child tickets.
My suggestion is to create a bundle in the Service catalog called 'New employee hire' with 7 additional items (that needs to be fulfilled for this ticket) .
a. The HR can request this bundle. When that request is submitted, the system automatically creates 7 child tickets which can then be assigned to any group/agent via automation rules or manually by the supervisor.
b. The supervisor can create a service request for the bundle whenever a new employee notification is received from the HR. Again, this will create 7 child tickets by the system and does not have to be done manually.
Does this help?
Adding the creation of Child tickets into the available dispatcher options would be great.
Right now, we trigger an automated email from our HR software into the helpdesk whenever a new user is onboarded. We, as an IT department, aren't about to tell the HR team that they have to fill out another form in FreshService in order to notify us that we need to create a new user.
If we could automate the creation of child tickets in the dispatchr , we would be able to distribute our workload without manually creating tickets for each new user.
For those of you also looking for this feature for a similar use case to mine, a workaround I would recommend is mailparser.io. You'll have to pay for it, but being able to take a single automated email and break it out into multiple emails makes task routing in this situation actually possible.
Hopefully you look into this. Or making tasks better.
I'm with Karim and Reese on this one.
We had to resort to the "additional items", but the problem with that is it does not carry the details entered in the parent ticket, so the agent working on the child ticket has to go to the parent ticket to get the details; otherwise, we would have to ask our HR to fill out the same information multiple times on the additional items.
For instance, we have different people in charge of creating accounts for different tools, so that means at least 3 child tickets via the additional items. These tools require information like name, position, access level, etc., that are already in the parent ticket. It's cumbersome to have to look at another ticket to get the details. We really do not want to ask our HR to fill out the new hire's details 4 times (once for the parent ticket and then once for each additional item). Right now we have it set for the agents assigned to the additional items to check the details in the parent ticket.
Another option that would help is to allow us to create a ticket using the ticket rules. We can create a rule depending on the responses in the service item, and then have a ticket created and assigned to a specific agent or group.
I also agree on having the option to hide the service items for the additional items, since they are only addons and should not be visible as a separte service item in the catalog.