Freshworks named the only Challenger in 2021 Gartner® Magic Quadrant™ for ITSM tools. Access Report

Start a new topic

Sharing ticket with multiple requesters

I haven't found an easy way to share ticket details with multiple requesters.

While I can CC users in the emails we sent from the helpdesk, only the main requester can see the ticket on the Support Portal.

When using support ticketing systems like Zendesk they allow multiple users to follow tickets and browse organisation requests in their helpdesk. 

We could allow everyone see tickets from their department but many tickets are shared across departments and this would open up other issues as well.

I've reported this via support ticket 9 months ago: 

75 people like this idea

this feature would be nice to give more options for key users

1 person likes this

We have come across issues relating to this a number of times.  Sending a bulk action reply, for example, only sends a message to the "original" requester and doesn't contact anyone that would usually be CC'd in for a standard reply, leading to a lack of notification of the update.

We also have a number of cases where one of our department "reception" position will forward on external customer/member emails which we then have to edit the requester line in order to more reliably respond to the originator of the problem. 


We really understand the usecase where you require access to a Ticket for multiple members.

The design is that, as Freshservice is an ITSM tool we restrict the Ticket access only for the User as there might be confidential information such as password or such. We have the option to use "cc" which would notify other members of ticket updates.

Also, we allow the Users to view tickets from their corresponding department but this might not solve the users to watch tickets for other departments.

A suggestion that we could provide is that you can include the Public Ticket URL ({{ticket.public_url}) Placeholder in the "CC" notifications from Admin --> Email Notifications, using which the cc'ed user would have access to the ticket too.

Let us know if this would solve the pain points that are mentioned here.



1 person likes this

This would be extremely useful as an issue came up today that ended up confusing a user who was CC'd in on a ticket. They were sent an email inviting them to see the ticket, but they did not have permission to do so.

Maybe just allow us to add multiple people to the "requester" field and when CC'ing give us the option to "add as requester" for each CC or just a regular email CC.

The issue of confidential information or discussion about someone's ability then later CC'd into the ticket is much less of a concern than the usability of the system in this regard.

Public ticket URL wouldn't really solve the issue if we are trying to direct people to use the portal and then to be notified when closed etc.

2 people like this

We definitely understand the use case here of adding multiple people to a Ticket, as Raj mentioned this is a design of the Product where we have not provided this option as the Ticket might have confidential inputs and there is a chance of looping the third party accidentally as well.

Our Product team is aware of the added functionality that this feature can bring and we are looking at the best way of enhancing the same.

I will have this topic moved to the Feature request forum and will keep you posted on further updates.

Another possible good solution would be if user could view the tickets they are cc'ed in in their user portal.

5 people like this

We would like this one as well. I don't like restriction and explanation that "Ticket might have confidential inputs". Please leave this "risk" with us...

12 people like this

+1 Would be really helpful to have a solution for this

This is our #1 request as well.

1 person likes this

This is our request as well

Use case: we offer 2nd line+ support only. Our clients take on 1st line support. This means that in addition to the specific requester, we need to keep a group of client helpdesk users up-to-date on developments to a ticket. 

In effect we'd need to be able to put a requestor group to a CC. We don't use the portal (yet) so a link is not an option. Agree with earlier feedback that the confidentiality concern should be an admin decision rather than a product design decision. Make it configurable to allow / not allow CC'ing requestor groups and that concern is addressed, whatever approach an admin may wish to use?

1 person likes this

+1 this is something we are looking for as well. Our HR department put in request for new employees, and they CC the managers of said employees. These managers need to see what HR has requested for the new employee

1 person likes this

We just moved to FreshService, and to be quite honest, this kind of functionality is so widespread and standard that we'd assumed it would be here too.

To add to the pile of use-cases in this thread: we often get duplicate incident reports from people, especially with shared resources in our office or in the case of some widespread problem. The best way we know how to manage these kinds of things is to consolidate (i.e. merge) tickets together, so that there's one place for us to broadcast updates to impacted users. We also often have tickets that involve multiple non-agent stakeholders that must be updated through and participate in the ticket's comment thread.

From what we can tell so far, it looks like our only option for these cases is to not use FreshService for anything but our task-tracking, and to shell out conversation to something else.

In the year since this thread started, has there been any updates on this feature work?

2 people like this

Another use-case, using existing functionality: two tickets with different requesters are merged together.

Expected: the new consolidated ticket (which has other information merged into it) would have both people as co-requesters.

Actual: the requester from the merged ticket gets dropped from the consolidated ticket. The only way to keep all parties in the thread seems to be to manually CC them on each reply.

This kind of thing is quite unexpected, given the taxonomy of "merge" in most contexts. Is it possible to get this behavior filed as a bug report?

1 person likes this

+1 for this feature!

Login or Signup to post a comment