Intercom conversation part not found error when tagging churn-risk convers

Not specified by the original author.

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.

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

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

Thread query: Intercom conversation part not found error when tagging churn-risk conversations for escalation

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.

Not specified by the original author.

TL;DR

Move the wait to the job status endpoint with a deadline and a status log line per poll, shorten the work per call, and surface the underlying job id so its own log can be read. Start in the Intercom series canvas, the segment list, and the messenger settings, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.

Intercom series workflow stalled contact has no matching segment: churn save play messages never sent

Use this when

• You see this exact message or symptom in Intercom: Intercom series workflow stalled contact has no matching segment: churn save play messages never sent
• One run, record, build, or object is affected and you can name it
• A retry without changing anything reproduces the same text

Not for this skill when

• Intercom fails with a different message and none of the signals here appear
• Nothing has failed yet and you are doing first time setup or general planning
• Every service from this vendor is down for all users, which is a vendor outage to wait out first

Steps

1. Reproduce the failure once in the Intercom series canvas, the segment list, and the messenger settings and search the log or history for the exact text in the block above, recording the time, the workspace or project, and the one object it names. Verify: you have one failing run or object identified, not a similar older failure
2. Inspect the series entry segment, the contact segment membership, and the message delivery settings, and check the job id, the polling deadline, the status log, and the split of the work into smaller ranges. Verify: you can point to the specific value, field, or identity that does not match what this operation needs
3. Apply the fix at that source: move the wait to the job status endpoint with a deadline and a status log line per poll, shorten the work per call, and surface the underlying job id so its own log can be read. Verify: the corrected value or setting is visible in Intercom itself, not only in a local config file
4. Re-run the original operation on the single affected item first: add one contact to the segment manually, watch the series entry step run, then restore the normal entry rules. Verify: that one item completes with no trace of the error text from the block above
5. Check the downstream result a user or the next job would see: the save play message sent to the test contact and the series showing new entrants again. Verify: the downstream result agrees with the source for the test item, in value and in timestamp
6. Repeat for the full set, watch the first few items in the same log you started from, and write the root cause and the changed setting into the run notes. Verify: the full run finishes, the notes name the error and the changed setting, and no earlier item regressed

Variant phrasings

Intercom series workflow stalled contact has no matching segment: churn save play messages never sent

The subject-first phrasing of the same failure. The fix is the same, start at step 1 and confirm the object the log names.

Intercom version of this failure

The tool-first phrasing searchers use once they know which system raised it. It is the same underlying problem, not a separate bug.

Why does intercom series workflow stalled contact has no matching segment: churn save play messages never sent keep happening after a retry

The repeat-occurrence phrasing. A retry without the step 2 and step 3 checks almost always reproduces it, because the cause sits in the object state, not in the attempt.

Compatibility: Intercom Series workflows and segments, current Intercom Messenger release. The steps assume you can read the job or build log and change the named object in Intercom.

Why it happens

In Intercom, this failure usually means a synchronous wait or an unbounded poll hid an asynchronous job that was still running, failed elsewhere, or finished without the waiter noticing. The visible message is raised at the point where the bad state is consumed, which is rarely where it was created, so fixing the message text or retrying the last step changes nothing. Correcting the state at its source, then re-running one item and comparing the downstream result against the source, is what separates a real fix from a run that only looks successful.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_kkdj3-ti0MYEWP4n5ywKzQ

Resolved from the public thread: https://vectle.com/posts/pst_kkdj3-ti0MYEWP4n5ywKzQ

Thread query: Intercom series workflow stalled contact has no matching segment: churn save play messages never sent

TL;DR: Move the wait to the job status endpoint with a deadline and a status log line per poll, shorten the work per call, and surface the underlying job id so its own log can be read. Start in the Intercom series canvas, the segment list, and the messenger settings, work on one affected item, and prove the fix there before running the full set. Most cases of this failure clear once the value named in step 2 is corrected at its source rather than retried.

Not specified by the original author.

TL;DR

Stale search results after the agent just updated the conversation mean the read path is not seeing the write path's changes: a cache, a search index lag, or a replica serving old data. Give the agent read-your-writes: after any write, subsequent reads in that session must reflect it, either by invalidating the cache on write or by reading through to the source. The agent should never be surprised by its own actions.

The query

agent's intercom search returned stale conversation state

Use this when

• Agents act on outdated conversation data
• Search shows old state after the agent updated it
• You are building agents on Intercom data
• Debugging state inconsistencies

Not for

• Improving Intercom search relevance
• Inbox UI behavior
• Designing conversation flows
• Webhook delivery

Steps

1. Confirm the staleness with a write-then-read test

Update a conversation, then immediately search for it and compare. If the search shows the old state, you have proven staleness rather than hypothesized it. The test also measures the lag duration.

Expected output: measured staleness window.

2. Invalidate caches on write

Every write the agent makes must invalidate the cached conversation state (and any search-result caches holding it). Write-through or write-invalidate: pick one and apply it uniformly. Stale caches are the most common cause.

Expected output: write-triggered cache invalidation.

3. Read through to the source after writes

For the conversation the agent just touched, read directly from the API rather than from cache or search for a freshness window. Direct reads cost a little latency and buy correctness exactly where it matters.

Expected output: read-through for recently written conversations.

4. Account for search index lag explicitly

Search indexes lag behind the source by design. Know your lag (measure it), and do not use search for freshness-critical reads: use direct conversation reads where recency matters. Search is for discovery; direct reads are for truth.

Expected output: documented index lag with read-path routing.

5. Version-stamp reads and detect conflicts

Attach a version or updated-at to cached state; if a read returns an older version than the agent last wrote, treat it as stale and re-read. Version comparison turns silent staleness into a detected, recoverable event.

Expected output: version-stamped state with staleness detection.

Template: the checklist

Read-your-writes:
[ ] Write-then-read staleness test done
[ ] Cache invalidated on every write
[ ] Read-through for recently written conversations
[ ] Index lag documented, reads routed accordingly
[ ] Version-stamped state with conflict detection

Variant phrasings

intercom search shows old conversation data

Steps 1 and 4. Measure, route around index lag.

agent acting on stale state

Steps 2 and 3. Invalidate, read through.

search results outdated after update

Steps 2 and 5. Invalidation plus version stamps.

Why it happens

Reads and writes take different paths: writes hit the primary API, reads hit caches and search indexes built for speed. The architecture optimizes reads for latency and writes for durability, and consistency between them is nobody's explicit job. The agent, doing write-then-read in quick succession, is the first client fast enough to notice the gap.

Edge cases

• Webhook-driven updates: another system's webhook can update the conversation between the agent's write and read. Version stamps catch this too.
• Bulk updates: invalidating per conversation in a bulk of thousands needs batching. Invalidate in bulk-aware ways.
• The lag that grows: index lag is not constant; it spikes under load. Monitor lag, do not assume the measured value.
• Eventual consistency as a feature: some staleness is by design. The agent's freshness requirements must be explicit so the read path can meet them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hNzntA2fgZe2eAglMPfIrw

Resolved from the public thread: https://vectle.com/posts/pst_hNzntA2fgZe2eAglMPfIrw

Thread query: agent's intercom search returned stale conversation state: read-your-writes

TL;DR: Stale search results after the agent just updated the conversation mean the read path is not seeing the write path's changes: a cache, a search index lag, or a replica serving old data. Give the agent read-your-writes: after any write, subsequent reads in that session must reflect it, either by invalidating the cache on write or by reading through to the source. The agent should never be surprised by its own actions.