Sometimes the wrong person ends up attached to a ticket — a coworker forwards a client's email, a shared inbox address gets picked up as the customer, or someone else in the thread gets bound as the owner by mistake. Now you can fix that directly, without losing any of the conversation history.
What it does
Changing the requester rebinds an email ticket to a different customer — either someone already in your organization or a brand-new customer created on the spot. The full thread stays intact, and an internal system note is added documenting the change so there's a clear record of what happened and when.
Everything that depends on "who this ticket belongs to" updates automatically:
- The ticket sidebar and recent-ticket history
- Any plugins tied to the customer (e.g. billing)
- The reply composer's To field
If you have CC email routing enabled, you can optionally keep the previous requester on Cc — this is off by default, so nothing gets added unless you choose it.
When to use it
Good fits:
- A client emailed through a colleague's forward, and the colleague (or a generic address) became the requester instead of the client.
- The wrong contact was selected when the ticket was created or during early triage.
- The ticket should belong to the account holder who'll actually continue the conversation — and who should see it in the self-service portal, if that's enabled for your org.
When to be careful:
- Just fixing a typo in a name? If it's not an identity change, this isn't the right tool — look at editing customer details instead.
- Plugins keyed to the customer's email (like billing) will start reflecting the new customer's data once the change is made, and may stop showing anything for the old address.
- Self-service portal enabled? The new requester gains portal access to the entire thread, and the previous requester loses it. Worth knowing before you confirm.
- Non-email channels (like Telegram): this action isn't available — it's email tickets only.
How to do it
- Open an email ticket.
- Click the ⋯ Actions menu.
- Select Change requester.
- Review the current requester shown.
- Enter the new requester's email — type it or pick from the customer suggestions.
- If that email belongs to a new customer, a Name field appears; it's required.
- If your org has CC routing enabled, you'll see an option to keep the previous requester on Cc — check it if you want that, otherwise leave it unchecked.
- Read through the warnings shown (plugin behavior, self-service access) — they'll reflect your org's specific setup.
- Confirm Change requester.
After you confirm
- The ticket detail view refreshes to show the new customer.
- An internal note appears in the timeline recording the change.
- Plugins and recent-ticket history refresh to reflect the new identity.
- The reply composer's To follows the new customer, and Cc is reseeded from the ticket's updated recipient list — including the previous requester, if you chose to keep them there.
If you enter the same requester that's already on the ticket, nothing changes — no system note gets added.
Good to know
- This is available to any org member with access to the ticket's inbox — same access rules as other private ticket actions.
- It's not available on trial organizations. If you're on a trial and need this, reach out to support.
- It's not currently exposed to customers, the public API, or MCP.