Back to blog

Guide

How to investigate technical tickets that Intercom Fin escalates

Keep the customer conversation in Intercom. Connect the handoff to the code, logs, and configuration needed to resolve it.

Decimal and Intercom wordmarks on a white background with subtle marigold and sage halftone edges. Investigating Fin escalations.

A customer’s integration has stopped syncing. Fin has gathered details and handed the conversation to your support team. The customer has already tried reconnecting. It didn’t help.

Your next reply depends on understanding what happened inside the product. Was the connection rejected? Did a background job fail? Did the sync finish but skip the records the customer expected?

To investigate a technical ticket after Fin escalates it, start with the context already collected, identify one affected operation, and trace it through the relevant systems. Then bring the findings back into Intercom with evidence and a clear next step.

Decimal connects to Intercom and investigates connected code, logs, configuration, and customer data, drafting responses with citations for your team to review.

What should happen when Fin hands off a technical issue?

Fin supports escalation rules and guidance, with Workflows handling routing and actions after escalation. Configure a destination with an owner who can move technical investigations forward.

Before asking the customer another question, review what the conversation already contains. Preserve their description, any identifiers they supplied, the checks already performed, and why the issue remains unresolved.

For teams using Fin Procedures, Intercom recommends explicitly defining a handoff note that includes collected information, system checks, findings, and the reason for escalation. That context should become the starting point for the investigation.

Consider this illustrative ticket. The investigation and findings below are a worked example, not a customer case study.

Our CRM integration stopped syncing new contacts yesterday. It still says “Connected.” We reconnected it, but the contacts haven’t appeared.

“Connected” is a useful observation. Its meaning still needs to be checked against how the product determines connection status.

1. Find one operation you can trace

Start with one missing contact and the sync run that should have processed it.

Establish the customer’s workspace, the affected integration, the approximate time of failure, and an example record. Use information already available in the conversation and approved systems. Ask the customer only for what is missing.

What happened when this workspace attempted to import this contact?

That question gives the investigation a scope. It also helps prevent a similar error from another customer or environment being mistaken for the cause.

2. Follow the evidence through the product

For this example, the investigation should connect several observations:

QuestionEvidence to inspect
Did the sync run?Scheduler and job execution records
Did it reach the CRM?Outbound request logs and responses
Was access sufficient?The permission error and approved connection metadata
Why does the UI still say “Connected”?The code and configuration that determine connection status
Will missed contacts be imported later?Retry behavior, sync checkpoints, and backfill logic

Suppose the job logs show that the CRM rejected contact reads because a required permission was missing. The relevant code also shows that the “Connected” indicator reflects a saved connection, while sync failures are tracked separately.

Those findings explain how the customer can see an active connection while imports fail. But the investigation still has an open question: what happens to the missed contacts after access is restored? Check that before promising that reconnecting will recover them.

3. Turn the findings into a reviewable answer

A useful investigation makes it easy for support to see what is established and what remains uncertain. For our example, the internal findings might read:

  • Finding: Contact sync attempts are failing because the CRM rejects the contact-read request with a missing-permission error.
  • Evidence: The affected workspace’s job logs show the rejected requests. The connection-status code explains why the integration continues to display “Connected.”
  • Next step: Have an authorized CRM administrator restore the required permission, then verify a new sync attempt.
  • Still to verify: Whether the next successful run includes contacts missed during the failure window.

Attach source references to the findings. A reviewer should be able to inspect the relevant job, configuration, or code without recreating the search.

With the appropriate sources connected, Decimal helps perform this investigation and drafts a cited response within the support workflow. What it can establish depends on the evidence and permissions available to the workspace.

4. Tell the customer what you found and what happens next

The customer-facing response should explain the problem in terms they can act on. For the illustrative case:

We found that the CRM is rejecting contact sync requests because the connection is missing a required permission. The “Connected” label confirms that the connection is saved, but the contact import is failing. Please have your CRM administrator restore the contact-read permission. Once that’s updated, we’ll check the next sync attempt and confirm how to recover the contacts missed since yesterday.

The exact permission name and instructions should come from verified product information. Keep internal logs and implementation details in the investigation unless they help the customer take the next step.

5. Give engineering a specific unresolved question

Some investigations still need engineering. In this example, support may establish the permission problem but discover that recovery behavior is unclear. The escalation should preserve that progress:

Contact imports failed during this interval because of a missing CRM permission. Access has now been restored. Please confirm whether the next sync includes the missed interval or requires a backfill. Attached: affected workspace, example record, failed and successful job references, and the relevant checkpoint logic.

Engineering can begin with the recovery question. Support can continue explaining the situation to the customer without asking them to repeat the original report.

Bring investigation into your Intercom workflow

Start with a recurring type of technical escalation, such as failed integrations. Identify the sources needed to resolve those tickets, connect the approved context, and review the resulting investigations with your support team.

Decimal is available through the Intercom App Store. Setup includes connecting Intercom and configuring the product sources and access needed for your investigations.

Bring a recent Fin escalation to a Decimal demo and see how the investigation connects the customer’s report to the evidence behind it.

Sources

See Decimal investigate a Fin escalation

See Decimal on your own issues.