Intercom Run Assignment Rules Removal Before December 31, — when and how should I migrate?
Teams automating Intercom conversations need to choose a replacement workflow for assignment logic before the Run Assignment Rules action is removed at the end of 2026.
Blockers
- deprecated in API version 2.12 and later; 2.12+ no longer supports rule reruns
- capability/run-assignment-rules — EOL 2026-12-31
- deprecated endpoint page points to Assignment Rules as the native mechanism for assigning conversations
- official FAQ says teams can assign directly with Manage Conversation API instead of running saved assignment rules
- official replacement pattern is to receive webhook events, evaluate routing externally, then call Manage Conversation to assign
Who this is for
- low-ops
- small-team
- enterprise
Candidates
Replace reruns with explicit assignment via Manage Conversation API
Intercom's official developer FAQ says teams can assign a conversation directly to an admin or team with the Manage Conversation API instead of running saved assignment rules. As of 2026-03-21, Run Assignment Rules is deprecated in API version 2.12 and later, and the endpoint is scheduled to fail completely after December 31, 2026. The cited docs show Run Assignment Rules required Inbox Pro, but Intercom does not expose a current numeric price for direct assignment in these docs, so check official pricing docs for current packaging. The differentiator is determinism: your app computes the assignee and sends the final assignment directly.
When to choose
Use this when you already have routing logic in your own backend and want the least ambiguous migration path. It is the best fit for teams that can own assignment logic themselves and do not need Intercom to re-evaluate inbox rules after each event.
Tradeoffs
You remove dependence on a deprecated endpoint and avoid version pinning, but you now own routing logic, assignee resolution, and fallback handling.
Cautions
Do not plan around API version 2.12+ supporting rule reruns; as of 2026-03-21, that removal has already occurred. You also need the Intercom conversation id plus the target admin_id or team id.
Build an event-driven router with Intercom webhooks plus direct assignment
Intercom webhooks let your app react to conversation events, and the webhook reference includes assignment- and conversation-related topics such as "conversation.user.created" and "conversation.admin.assigned". As of 2026-03-21, this is the cleanest official pattern for replacing "rerun assignment rules" with custom automation: receive the event, evaluate routing externally, then call Manage Conversation to assign. Intercom's cited webhook docs do not publish a separate price for webhook usage, so check official docs for current plan packaging. The differentiator is that you preserve event-driven automation without depending on the removed rule-rerun API.
When to choose
Use this when assignment depends on conversation lifecycle events and you still want automatic routing after creation, replies, or reassignment triggers. It fits enterprise or integration-heavy setups better than small scripts because it requires a public endpoint and reliable retry-safe processing.
Tradeoffs
You keep automation flexibility and can route on arbitrary business rules, but you add webhook infrastructure, idempotency concerns, and operational complexity.
Cautions
Treat webhook handling as at-least-once delivery and make assignment operations idempotent. This is more moving parts than native inbox routing, so it is not the lowest-ops option.
Move routing back into Intercom-native assignment rules and automations
Intercom's deprecated endpoint page still points to Assignment Rules as the native mechanism for assigning conversations, and it notes that Run Assignment Rules was available only with Inbox Pro. Intercom's Fin AI Agent help page says Fin follows existing assignment rules, automations, and reporting, which indicates native routing remains the preferred in-product path even as the rerun endpoint disappears. As of 2026-03-21, the main blocker is architectural rather than price: if your workflow depends on re-triggering rules from code, API version 2.12+ no longer supports that. The differentiator is lowest operational overhead because routing stays inside Intercom instead of your backend.
When to choose
Use this when your assignment logic can be expressed with Intercom's own inbox rules and you want the smallest external integration footprint. It is the best fit for low-ops teams that can accept Intercom-native routing instead of custom code-driven reruns.
Tradeoffs
Operationally simpler and closer to Intercom's supported path, but less flexible than owning routing logic in code.
Cautions
The deprecated endpoint explicitly says it cannot be used with Workflows, so do not assume workflow adoption preserves the old rerun behavior. If your current automation depends on mid-conversation re-evaluation from code, validate that native rules cover those cases before migrating.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Intercom Run Assignment Rules Removal Before December 31, — when and how should I migrate?"