## TL;DR
The part your automation is tagging probably is not the part Intercom thinks exists. Tagging and escalation flows that act on a conversation part fail with part not found when the code stored a part ID from an earlier fetch, the conversation gained or lost parts, or the integration confuses the conversation ID with a part ID from a reply. Re-fetch the conversation, act on a current part or on the conversation level your plan supports, and make the tag step idempotent so retries stop erroring on work already done.

```text
Intercom conversation part not found error when tagging churn-risk conversations for escalation
```

## Use this when
- The tagging automation logs part not found errors against conversations that open fine in the Intercom inbox
- Failures cluster on older conversations, reopened conversations, or conversations with many replies
- Manual tagging of the same conversations in the UI works

## Not for this skill when
- The conversations were deleted or are in a workspace the integration token cannot access
- Intercom is returning errors for every call type, indicating a platform incident

## Steps
1. Take one failing conversation ID from the logs and open it through the Intercom API, listing its conversation parts with their IDs, types, and timestamps. Compare the part ID your automation tried to use with the parts that actually exist now, and note whether the stored ID appears at all, appears under a different conversation, or belongs to a part type the tagging endpoint does not accept. Verify: the stored part ID is classified as stale, foreign, or of an unsupported type
2. Trace where the stored part ID came from in your pipeline. Common sources are a webhook payload captured at conversation creation, a nightly export that ages quickly, or code that treats the ID of the initial message part as permanent while agents and customers add replies. Measure the age of the IDs your automation holds, because staleness grows with every hour of delay. Verify: the ID source and its typical age are identified
3. Change the automation to fetch the conversation fresh at tagging time and select a valid current part, normally the most recent part or the initial part as returned now, or move the tag operation to the conversation level if your workflow and Intercom plan allow tagging the conversation directly. Keep the choice consistent so tags land predictably for reporting. Verify: a fresh fetch based run tags the sample conversation successfully
4. Make the step safely repeatable. Before tagging, check whether the churn-risk tag is already present, and treat already tagged as success rather than an error, so retries, webhook replays, and overlapping nightly runs stop producing part errors for conversations that were handled on an earlier pass. Verify: a repeat run over the sample conversation completes with no error and no duplicate tag
5. Sweep the failure backlog. Re-run the corrected tagging over every conversation that errored in the window, confirm the escalation tag or assignment appears in the inbox for a sample, and hand CS a count of conversations that were at risk of being missed so they can prioritise review of the oldest ones. Verify: the backlog is processed and the missed escalation count is reported with the oldest cases listed first
6. Add error handling that separates permanent failures from transient ones. Part not found for a conversation that still exists should page the integration owner after a small number of occurrences, because it signals data drift, while a deleted conversation should be logged and dropped quietly. Record part IDs only in short lived logs, never as long term state. Verify: the alerting split exists and a test stale ID produces the intended alert

## Why it happens
Intercom conversations are living objects. Parts are added as people reply, assignments change state, and exports or webhook snapshots age immediately. An automation that stores a part ID and acts hours later is acting on a photograph, not the conversation, and Intercom correctly reports that the part it was handed cannot be found in the form expected. The conversations were escalatable the whole time, only the pointer was stale.

Compatibility: Intercom conversations API, conversation parts, tags, and webhooks, in current Intercom API versions, with inbox escalation workflows.

## Variants and edge cases
### Intercom conversation part not found tagging API
['The direct phrasing. Fresh fetch at action time is the durable fix, stored part IDs are a cache with no invalidation and will keep expiring under you.']

### Intercom tag conversation via API part ID error
['The implementation variant. Check the endpoint documentation for whether your call expects a conversation part ID or the conversation ID itself, a mix-up that produces this exact error.']

### churn-risk conversations not escalated Intercom automation
['The business variant. Quantify missed escalations during the failure window and review them manually, because fixing the tagger does not recover the response time those customers lost.']

Edge cases to work through before you close the incident:
- Some part types, such as internal notes or system events, may not accept the operations a normal reply part accepts. Always select a part of a type the endpoint supports.
- Closed conversations may need reopening before certain actions. Handle state explicitly rather than treating a state refusal as a missing part.
- If you tag for reporting, audit tag consistency after the fix. A backlog sweep can double tag under a variant tag name and split your churn reporting.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qy8mdJeJl-XliSIZWSrq2g