Intercom

Optional · Connect existing tools

Use Intercom integration only if your team already uses Intercom and needs its conversations to become Supportbench cases. The integration connects two systems; it does not replace the support owner or prove a customer issue is resolved when a conversation closes.

Before you begin

Use a Supportbench administrator with integration-editing permission and an authorized administrator of the intended Intercom workspace. Have the receiving division, priority and monitored fallback queue ready. Prepare a controlled conversation and contact email for testing.

If you do not use Intercom, mark this chapter not applicable and continue. Do not create or connect a third-party account solely to finish onboarding.

Connect and configure

Open Settings → Integrations → Intercom.
Inspect the current connection and workspace before changing anything.
If disconnected, select Connect Intercom and complete the provider authorization with the intended workspace. Review the requested access and verify the workspace shown on return.
After connection, the routing controls become available. Choose the permitted Division, Priority and fallback Queue. The fallback is used when an Intercom assignee does not match an active Supportbench agent.
Review Create a Case using the current mapping below. Do not choose an event by its label alone.
Decide whether to enable Require a contact email before creating a Case. A conversation without the required usable email will not create the expected case.
Review Use Intercom Help Center for AI answers only when the published provider content is an approved knowledge source.
Save the settings, reopen and confirm the values.
Select Verify connection to check the saved installation.

Intercom is not connected in the demo. Connect Intercom starts provider authorization; routing settings appear after a compatible connection. No provider account was connected or test conversation sent.

Understand current behavior before choosing a trigger

The published Core reference documents a mismatch between two visible choices and processing:

Visible Create a Case choice	Current processing described by the Core reference
Never	No new-case creation milestone; existing linked conversations can still update.
When the conversation starts	Conversation-created event.
When the conversation is assigned	Conversation-closed event.
When the conversation closes	Conversation-assigned event.

Treat this as a product limitation requiring a controlled test. If conversation-start creation fits your process, it avoids that label ambiguity.

The saved Close the Supportbench Case when Intercom closes switch is not consumed by the current conversation processor to close cases; linked updates can also set the case back to Open. Keep an explicit case-completion responsibility. See current Intercom configuration and limitations immediately before changing the integration.

Verify the operational handoff

Start an approved test conversation with a controlled contact email.
Exercise the actual configured creation event.
Find the resulting Supportbench case and verify customer identity, division, queue and owner.
Add a harmless follow-up in Intercom and inspect the linked case update.
Close the test conversation and inspect the actual Supportbench status. Complete remaining support work explicitly.
Confirm who will update the customer and when. A provider connection check does not prove event delivery or correct ownership.

Recover common failures

If no case appears, inspect the actual creation milestone, email requirement, workspace and conversation identity. If the owner differs, check active-agent matching and the fallback queue, then later workflows. If the case remains open or reopens, handle it according to the documented current behavior instead of assuming the switch guaranteed closure.

Save or cancel pending edits before reconnecting, verifying or disconnecting. Disconnect Intercom removes the local connection/mapping; provider-side app removal is separate. Review active support obligations before disconnecting an existing installation.

Completion check

The integration is intentionally selected or marked not applicable.
The authorized workspace and routing are verified.
The actual creation milestone was tested.
Follow-up updates and actual closure behavior were observed.
Customer communication retains an accountable owner.

Previous: Choose and verify AI assistance · Next: Azure DevOps