Reference · built on requestOperator by FibricCustomer support

Thread Merge

Finds the same customer's open email, chat, and call threads. Proposes merging them under one owner with the combined history.

Request accessPricing ↗

About

A customer emails, gets no answer in an hour, opens a chat, then calls. Each agent now holds a piece of one question. Thread Merge reads open conversations by customer across the support tool and the phone system, matches them to one person through the CRM's email and phone identities, and proposes a single merged thread: which one is the target, which are folded in, and who owns the result.

Because every support tool treats a merge as permanent, nothing merges until an agent approves the exact pair. Where a merge is blocked, by a merge lock or by different requesters, the operator proposes a link instead. The record keeps the ids of everything that was folded in.

This is a reference listing. It documents what Fibric would read from Thread Merge and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Open conversations on one customer timeline in Kustomer across email, chat, SMS, and voice, and the mergeLocked attribute on each
  • Open Zendesk tickets by requester with status, channel, and assignee; only tickets below Solved can be merged into another
  • Gorgias tickets by customer and channel, and the ticket-merged event once a merge has happened
  • Front conversations by contact with assignee and inbox, and the conversations_merged event carrying deleted_conversation_ids
  • Calls in Aircall with contact, user, started_at, and tags, so a call can be matched to an email thread from the same person
  • Contacts in HubSpot fetched by email with idProperty=email, so one person is matched across addresses and numbers

Proposed actions

  • Target capability: propose merging the customer's open threads into one, naming the target, the sources, and the combined history in time order
  • Target capability: propose one owner for the merged thread: the agent who last replied, or the assignee you name for that channel
  • Target capability: propose an internal note on the target listing the threads folded in and why, written before the merge runs
  • Target capability: propose linking instead of merging when a Kustomer thread is merge-locked or Zendesk tickets have different requesters

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Bring an email and a chat together

    A customer's email and chat about one order sit open in Kustomer on the same timeline. The operator proposes the email as target and the chat as source; an agent approves and the messages appear in order.

    With Kustomer

  • Merge two tickets from the same requester

    Two Zendesk tickets match one HubSpot contact by email. The operator proposes the merge, the owner, and the note. Zendesk tags the closed ticket closed_by_merge and keeps its last public comment on the target.

    With Zendesk, HubSpot

  • Attach the call to the email thread

    An Aircall call from a number on a Gorgias customer lands while their email ticket is open. The operator proposes the merge, which Gorgias allows when the customer matches on both.

    With Aircall, Gorgias

  • Merge in Front and keep the owner

    Two Front conversations from one contact sit in different inboxes. The operator proposes the merge and the assignee who last replied; the conversations_merged event confirms it and records the deleted ids.

    With Front

Requirements

  • A support connector with a merge operation: Kustomer, Zendesk, Gorgias, or Front
  • A contact center connector for call threads: Aircall, Amazon Connect, or Dialpad
  • A CRM connector to match one person across identities: HubSpot or Salesforce Sales Cloud
  • Merge permission for the account the operator acts as; in Zendesk Enterprise, custom roles need it granted
Authentication
Runs on the credentials of the support, contact center, and CRM connectors you attach, with merge permission granted to that account. No credential is kept by the operator.

Limits

  • Merges are permanent in Kustomer, Zendesk, and Gorgias. None of the three offers an unmerge, so the operator never merges without an approved pair
  • In Kustomer only the parent conversation keeps its data. Fields on the conversation merged away are not carried over
  • In Zendesk only the most recent public comment of the closed ticket is copied into the target, with a link back to the closed ticket
  • Gorgias requires the customer on both tickets to match for voice and SMS merges. Email tickets can merge with other types

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Thread Merge ↗

Questions and answers

What does the agent approve before a merge?
The exact pair or set: the target thread, each source thread, the proposed owner, and the note. The agent can swap target and source, drop a thread, or choose a link instead. Because merges cannot be undone, nothing merges before that approval, and each merge runs once.
What record survives a merge?
The note on the target naming every folded-in thread by id and channel, the owner set, who approved, and when. Where the tool emits a merge event, its id is kept too: ticket-merged in Gorgias, conversations_merged in Front, closed_by_merge in Zendesk.
Does it merge threads that only look similar?
No. It proposes merges only for threads matched to one person through the CRM or the support tool's own customer record. Threads from different requesters, or a thread that is merge-locked, get a link proposal, not a merge.
Ask about Thread Merge

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy