Receive case email alerts and reply through the correct Supportbench thread

Updated Wednesday, October 28, 2026 · Marc Staine

A reply-capable case notification lets an agent respond from an email client while Supportbench records the conversation on the case. This can help a specialist contribute to a complex B2B investigation without losing the shared history. It also has consequences: an accepted reply can create an outbound customer email, affect ownership or watching, and trigger case processing. Verify the thread and recipient before sending.

At a glance

For: agents who monitor case updates through email and administrators supporting that workflow. Applies to: Supportbench Core.

Start here: Profile → Settings → Notifications; your approved email client; Case View

Reply to a case notification safely · Enable the email channel and verify eligibility · Understand what the generated reply address does · Check communication, ownership and state separately · Understand #close and #closereply before using them · Example: a specialist responds while another agent owns the case · Troubleshoot notification replies

Reply to a case notification safely

Open the received notification and verify the case ID, customer context and recent conversation. If it is stale or unclear, open the current case before answering.
Choose Reply in your email client and inspect the destination address. A supported reply-capable notification uses a generated address containing +reply and an activity identifier. Keep that address intact.
Send from the email identity associated with your Supportbench agent account. Do not forward the notification to another mailbox and assume that person inherits your agent identity or authority.
Write the response for the intended customer audience. Remove quoted notification details that should not be included in the outgoing message. Review attachments and your email client’s signature.
Do not add closure hashtags unless your team has specifically approved and verified that workflow. A normal reply is sufficient when you only intend to answer the customer.
Send once, then open the case in Supportbench. Confirm the new outbound activity, its content, intended recipient and send outcome, plus the current owner and state.
If the outcome is uncertain, inspect the case before sending the same email again. A delayed client response or notification is not proof that processing failed.

Treat a +reply message as customer communication

When the route accepts a generated reply address, Core can create an outbound activity addressed to the sender of the referenced activity and queue it for email. An activity’s internal/private visibility marker is not a guarantee that this email reply stays inside the team. Use a native internal note for an internal-only contribution.

Enable the email channel and verify eligibility

In Supportbench, open the avatar/profile menu and select Profile.
Open Settings → Notifications and enable Email alerts if this is part of your team’s monitoring process.
Choose Save profile and reopen it to confirm the saved value. Confirm your agent email identity through the appropriate profile administrator.
Verify a representative eligible event through an approved internal workflow. Check the actual message, its case reference and whether it provides the reply-capable address.
If it does not arrive, investigate event eligibility, watching/queue context, outbound delivery and inbox filtering separately.

Email alerts does not mean every bell item or every incoming message in the account is emailed to you. Watches, event rules, profile settings and delivery conditions still apply. A notification that lacks the supported reply address should not be treated as the same reply-through-case workflow.

Understand what the generated reply address does

The +reply address identifies the prior activity so the incoming processor can associate your response with its case. The base address must resolve to a configured Supportbench sender address in the account. Keep the complete address supplied by the notification; do not build one manually, remove the identifier or copy an address from a different case.

The sender of your new email is evaluated separately to identify the responding agent. The thread identifier answers “which activity is this about?” while the actual sending address helps answer “who is responding?” A forwarded notification does not make its new reader the original agent.

For a successfully matched reply, the outgoing target is based on the referenced activity’s sender. If a case has multiple customer contacts or the conversation has moved to a different person, open Case View and use the normal outbound composer to choose recipients deliberately. Do not assume that clicking Reply All in your email client is equivalent to Supportbench’s native Reply All behavior.

Check communication, ownership and state separately

Result	Current behavior and verification
Case history	An accepted generated reply creates an outbound reply activity on the resolved case. Check the actual activity and content.
Customer delivery	Core queues the outbound message to the referenced activity’s sender. Queueing is not proof of final inbox delivery; inspect the send outcome and any failure.
Previously unowned case	A recognized replying agent becomes owner when the case has no owner. Confirm the final saved assignment.
Case owned by someone else	The replying agent is added as a case watcher if needed; the existing owner is not automatically replaced simply because another agent replied.
Case state	Incoming activity processing, closure hashtags and configured rules can affect the state. Inspect the result instead of assuming that sending an email leaves every case field unchanged.
Visibility	The activity’s public/internal marker and actual outbound email delivery are distinct. A private marker must not be used as a promise that the reply was not sent.

If you are assisting another owner, agree who sends the next customer update. The ability to reply through a notification is useful for collaboration, but it does not by itself establish a handoff or prevent two people from replying at the same time.

Understand #close and #closereply before using them

Current Core recognizes an agent’s hashtag from the first 100 characters of the plain-text email body. The sender must resolve to an agent, and the case must be an existing case for this closure handling. Formatting, signatures and quoted text can change where the parser sees a token, so a hashtag buried far down a long message is not a reliable command.

Token	Current processing	Operational caution
#close	Requests a closed case state and associates the new activity with that close operation.	The incoming activity and any applicable outbound reply queueing occur before closure handling. Do not use it to mean “close without emailing.”
#closereply	Requests a closed case state through the alternate close path after the new activity has already been processed.	It is not a separate guarantee of delivery, and does not undo an earlier outgoing queue operation.
Other extracted hashtag	Can be passed to configured hashtag-event workflows.	Only use a token your administrator has deliberately configured and explained. Arbitrary words are not universal built-in commands.

Use the native case actions when intent must be explicit

For a closure without customer email, open the case, record an appropriate internal note if needed, and use the approved native close workflow. For a customer reply followed by closure, review the outbound recipients/content and use the normal case workflow. Verify state and communication independently.

Older guidance describing #close as a guaranteed no-reply action does not match the current Core processing order. A critical account should not be used to test this distinction. Agree and verify any email-command workflow through an authorized controlled example before relying on it.

Example: a specialist responds while another agent owns the case

A customer’s integration contact provides the failed transaction time on an existing case. The assigned agent is coordinating updates, while a specialist receives an eligible email notification and can explain the next diagnostic step. The specialist first checks the current case to make sure the owner has not already answered.

If the generated reply targets the right customer contact, the specialist can send the agreed customer-facing explanation through that notification and then inspect the new activity. Because the case already has an owner, the reply does not automatically take over the case; the specialist can become a watcher. The owner remains responsible for the next agreed update unless the team explicitly reassigns the case.

If the specialist wants to share an unverified cause with the owner only, they should use an internal note or discussion in Supportbench. Sending that hypothesis to the +reply address risks turning it into customer email even if the resulting activity is marked private.

Troubleshoot notification replies

Problem	Checks and corrective step
No alert arrived	Confirm Email alerts, event/watch eligibility, correct agent address and actual outbound delivery. A browser bell event is not proof that an email was sent.
The reply did not appear on the intended case	Inspect the original +reply address, referenced case, sender identity and incoming-route result. Do not construct a replacement address from memory.
A new or unexpected thread appeared	Check whether the email client altered the recipient, subject or references and whether the generated activity address was retained. Use Case View to investigate before resending.
The activity exists but the customer did not receive it	Check the outbound send/queue result, target address and recipient filtering. Activity creation and inbox delivery are separate events.
The case owner did not become the replying specialist	Expected when another owner already exists. Check watching and use an explicit handoff if ownership should change.
Quoted notification details went to the customer	The email client may retain quoted content. Review and remove inappropriate quoted details before future sends.
A closure hashtag did not act as expected	Check recognized agent identity, existing-case context and the first 100 plain-text characters. Use the native case actions for an explicit outcome.
A private activity was still emailed	Visibility is not the email delivery switch for this route. Inspect the actual recipient and send outcome; use native internal notes for internal-only communication.

Was this article helpful?