TABLE OF CONTENTS
- Introduction
- How email conversations work
- Scenarios
- Key considerations for ticket creation and threading
Introduction
In Freshservice, a requester can send an email to a workspace’s support address to create a ticket in that workspace. They can also include multiple support addresses in the To, CC, or BCC fields. Freshservice then creates a separate ticket in each workspace so that every department receives the request in its own queue and can take action independently.
This feature is useful when getting help from multiple departments. For example, a requester may need assistance from more than one team or may not know which department owns the request. In this case, each department receives its own ticket. If the request is not relevant to a team, that team can close its ticket while the appropriate department continues the work.
This model ensures that all requests are tracked. Each workspace manages its own ticket from creation to resolution, while departments can work in parallel. This approach improves resolution times, increases transparency, and provides a smoother experience for employees.
How email conversations work
Freshservice keeps all related tickets updated by syncing the requester’s replies across them. This ensures that every team stays informed about the requester’s responses.
Note:
Agents in a workspace can have conversations on a ticket only with the requester, not with agents in other workspaces. To notify a support team in another workspace, the current option is to assign them a task or a ticket.
As an agent , if you add another workspace’s support address to a conversation, it will not create a new ticket. Tickets are created only when the requester includes those addresses in the original email.
Scenarios
The following scenarios illustrate how Freshservice handles requests sent to multiple workspace support addresses and how collaboration works.
Scenario 1: Requester replies selectively to one workspace
Let’s say, a requester sends an email to both IT and HR support addresses, two separate tickets are created, one in each workspace. When replying to the email thread, a requester can choose to send their response only to one workspace support address while excluding the other.
For example, if the requester replies only to the IT support address and excludes HR from the reply, the conversation continues only on the IT ticket.
The HR ticket does not receive these subsequent replies but remains open until HR closes it or resolves it independently.
Scenario 2: Requester adds a new workspace mid-conversation
If the requester includes an additional workspace support address in a reply. For example, adding Facilities while continuing the thread with IT, then Freshservice automatically creates a new ticket in the Facilities workspace.
The new ticket includes the full conversation history for context (unless removed by the requester)
Facilities can now collaborate alongside IT, while other workspaces can close their tickets if not relevant.
Scenario 3: When a ticket is moved to another workspace
When a ticket is moved from one workspace to another, there might already be an existing ticket in that workspace for the same request. Freshservice ensures that all related tickets created from the same original request stay synchronized. This prevents confusion for both the requester and the agents handling the tickets.
To understand this scenario better, imagine that a requester sends an email to the support addresses of IT, HR, and Finance. Freshservice creates three tickets.
T1 in IT
T2 in HR
T3 in Finance
Later, the IT team realizes that T1 is actually an HR issue and moves it to the HR workspace. At this point, HR has two tickets for the same request: T1 and T2.
When the requester replies, either to the original email thread or to a notification, Freshservice uses the requester’s email address and the conversation thread to identify related tickets. Because T1 and T2 both came from the same request, the reply is added to both tickets to keep them synchronized.
If multiple tickets within a workspace are tied to the same email thread, the requester’s reply is automatically added to all of them.
It is recommended that duplicate tickets be merged, with agents notified via a private note added to both T1 and T2 tickets upon T1’s movement to HR workspace.
Merging consolidates conversations into a single ticket so that agents and requesters don’t have to manage multiple threads for the same issue.
To merge tickets, follow these steps:
In the ticket view, click the More options (three dots) menu, and then select Merge.
In the side panel that opens, search for similar tickets by Requester, ID, or Subject. Click the (+) icon next to each ticket you want to merge.
Note: You can merge multiple tickets across different workspaces.
Confirm the primary ticket by clicking the Mark as Primary icon. All other selected tickets become secondary tickets. When tickets are merged, the secondary tickets are closed, and their conversations are moved into the primary ticket.
After selecting all tickets to merge, click Continue.
Review the primary and secondary tickets along with their workspaces, and then click Confirm and merge.
Note: After merging,the secondary ticket is closed and all requester replies are added only to the primary ticket. This keeps conversations consolidated in one place, ensuring clarity for both agents and requesters while preventing duplicate work.
Scenario 4: Deleting and restoring tickets
When a ticket is deleted in a workspace, it’s no longer available for updates or replies. However, Freshservice ensures that future replies from the requester aren’t lost.
If the requester replies to the original email thread, Freshservice checks for existing tickets in that workspace. If no ticket exists (because the earlier one was deleted), a new ticket is automatically created.
For example, suppose a requester sends an email to IT, HR, and Finance. Freshservice creates three tickets:
T1 in IT
T2 in HR
T3 in Finance
If an HR agent deletes T2:
The requester replies to the same email thread.
Since no open ticket exists in HR, Freshservice automatically creates a new ticket, T4, in the HR workspace.
This ensures that HR continues to be notified of the requester’s updates even though the original HR ticket was deleted.
Note that when a ticket is marked as spam or deleted, it moves to the Trash. If the ticket is later restored, any subsequent replies from the requester are added to both the restored ticket and the newly created one. For example, if T2 was deleted and a new ticket T4 was created in HR, restoring T2 means both T2 and T4 will now exist in the HR workspace and remain linked to the same email thread. Freshservice will then add requester replies to both tickets to keep them in sync.
Scenario 5: Archiving tickets
Ticket Archival is an admin-controlled process that moves closed tickets out of active workflows after a defined period. Archived tickets remain available for reference but cannot be updated.
For example, if an admin sets the archival period to 120 days, a closed HR ticket older than 120 days is automatically archived.
If the requester replies to the old email thread, Freshservice creates a new ticket in the HR workspace instead of reopening the archived one.
Key considerations for ticket creation and threading
1. When tickets are created from the email channel
When a requester sends an email to a workspace support address, Freshservice creates a ticket and associates it with the Message-ID from the email header.
The Message-ID enables:
Tracking the original conversation thread.
Syncing replies across multiple tickets if the requester emails several workspaces.
Maintaining conversation history even if the ticket is moved to another workspace. Any new replies to the original thread are appended to the ticket in its new location.
2. When tickets are created from the support portal
Portal tickets do not have a Message-ID by default. A Message-ID is generated only when an email notification is sent and the requester responds to it.
Behavior when moved to another workspace
When a portal ticket is moved to another workspace, if the requester replies to the portal ticket’s original email notification before receiving a response from the new workspace’s support team, a new ticket is created.
However, if the new workspace team replies first and then the requester responds, the responses are correctly added to the moved ticket.
3. Workflow automation emails
Emails sent by workflow automations to another workspace’s support address (To, CC, or BCC) do not create new tickets.
This is to avoid email loops between workspaces.
