TABLE OF CONTENTS


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.

Only one support ticket is created per workspace, even if the requester marks multiple teams within that workspace.


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:  Single ticket creation for multiple support addresses in one workspace

When a requester includes multiple support addresses from the same workspace in an email, Freshservice scans the To and Cc fields to identify the addresses used. If more than one address from the same workspace is found, the system adds a note in the same format as the ticket merger suggestion note. This creates only one ticket for that workspace.

System note example

This ticket was created from an email addressed to the following support addresses in the IT workspace:

  • {{address_1}} (mapped to agent group: {{agent group name}})

  • {{address_2}} (no agent group mapped)

  • {{address_3}} (either mapped or unmapped)

After creation, this ticket was assigned to {{address_1}} based on internal logic. You can take the next best action as needed.

The first email address listed above is the one mapped to the ticket.


Scenario 4: Ticket moved to another workspace (where a ticket already exists for the same email thread)

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:

  1. In the ticket view, click the More options (three dots) menu, and then select Merge.

  2. 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.

  1. 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.

  2. After selecting all tickets to merge, click Continue.

  3. 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 5: Ticket moved to another workspace (with no other ticket for the same email thread)

When a ticket generated from an email thread is moved from one workspace to another, Freshservice updates its internal mapping to maintain thread continuity.

To understand this scenario better, let’s say a requester sends an email to IT's support address. Freshservice creates a ticket T1 in the IT workspace.

Now, when T1 is moved from IT to HR:

  • T1 still exists in IT, but it is also represented as T1 in HR.

  • Any reply from the requester on the same email thread is added to the HR ticket.

  • This happens even if no HR agent has replied yet.

  • If different HR support addresses are used (for example, the requester replies to hr1@acme.com and the agent replies from hr2@acme.com), all replies are still added to the HR ticket.

  • Replies from other participants on the thread are also mapped to the HR ticket.

  • Similar to single-ticket movement, when an agent moves a ticket to a workspace that was not originally part of the email thread, Freshservice creates a new mapping for that workspace.

    Example:

  • Let’s say a requester sends an email that includes both IT and HR support addresses. Freshservice creates two tickets: 

    • T1 in the IT workspace 

    • T2 in the HR workspace.

  • Now, if an agent moves T1 to the Finance workspace, the ticket exists in three locations:

    • IT-T1, HR-T2, and FIN-T1

  • If the requester includes a Finance support address in a future reply, the response is added to T1 in Finance, even if no agent has yet replied from the Finance workspace.

  • If multiple tickets are moved to the same workspace, the system updates the mapping accordingly. That means, if the HR also moves T2 to Finance, both tickets are now represented as FIN-T1 and FIN-T2. Future replies to Finance are added to both T1 and T2. A system note is added to inform agents about the related tickets (T1 and T2).

  • Special case–Let’s say T1 is moved from Finance to Legal, while T2 remains in Finance. The mapping for Finance continues to include both T1 and T2, so any future replies to the Finance workspace are added to both tickets—even though T1 is now located in Legal.

Freshservice uses the message ID to ensure replies are mapped correctly. If the message ID is missing, the system falls back to the subject and then the content. If no match is found, a new ticket is created.


Scenario 6: 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.

If ticket T2 is restored from Trash before the requester replies, the reply is added to that same ticket. During restoration, if Freshservice detects another active ticket from the same email thread in the same workspace, then the system adds a ticket merger note to both tickets as below.

Ticket merger note:
“We've identified multiple tickets linked to the same email thread and associated with the {{workspace name}} workspace. Whenever the requester replies to this workspace, the reply will be added to all of these tickets. [Learn more]."


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 7: 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.