Why Your Intercom Workflow Is Silently Blocking Fin AI (And How to Fix It)

Plenty of businesses set up a workflow in Intercom, turn on Fin AI, and assume the two will just work together. Then conversations start going quiet. A customer opens the chat, picks a button, and nothing happens. Or Fin answers once and then never gets the chance to answer again, because a workflow keeps intercepting the conversation first. None of this is random. Intercom's workflow builder and Fin AI follow specific rules about who gets to respond and when, and most of the breakdowns trace back to a small number of setup choices.

Why This Keeps Happening

Workflows and Fin AI are not stacked on top of each other by default. Intercom decides which one handles a conversation based on triggers, audience rules, and the order of steps inside the workflow itself. If a workflow's trigger fires first and nothing in its path hands things to Fin, Fin never gets involved, even if it's fully enabled and trained on your help content. The reverse is also true: if Fin is set to handle the first message, your workflow might never fire at all. Neither behavior is a bug. It's just two separate systems with their own entry conditions, and if you haven't deliberately decided which one goes first, Intercom is deciding for you.

The Composer Problem

One of the most common causes of a silent Fin AI is a workflow that disables the text composer at the start of the conversation. This is usually done on purpose, to force customers through a button-based menu before they can type freely. The side effect is that Fin can't respond either, because Fin needs the customer to actually type a question. If your workflow opens with reply buttons only and the composer is turned off, Fin has no way in until a later step turns typing back on. The fix is simple once you know to look for it: check the very first step of your workflow and confirm "let customer type" or the equivalent composer setting is active before you expect Fin to pick up anything.

The Quick Reply Button Trap

Fin does not interpret quick-reply button clicks the way a workflow does. If a customer taps a button, Fin has no message to work from, since a button tap isn't the same as typed text. Teams often build a path where the last step is a button that's supposed to lead into a Fin-powered answer, and then wonder why Fin stays silent after the click. The way around this is to insert a message step after the button that explicitly asks the customer to type their question, or to use a canned reply that invites a real response. Without that nudge, you're handing Fin a conversation with nothing in it to read.

When "Customer Sends Any Message" Breaks Everything

A workflow trigger that fires on any message from the customer, not just the first one, is one of the easiest ways to create a loop that fights with Fin. If that trigger sits in a workflow that also contains a Fin step, every message the customer sends after the first one can re-trigger the workflow path, even after a human teammate has taken over the conversation. The practical result is Fin, or the workflow logic around it, keeps replying on top of your support team's messages. Reassigning the conversation or adding an internal note does not stop this on its own. If you need automation to run on an ongoing basis, build it on a narrower trigger, and keep "any message" triggers out of paths that also route to Fin.

Audience Overlap Is Quietly Stealing Conversations

Workflows and Fin both use audience targeting rules to decide who qualifies for them, things like plan type, location, or custom attributes. When a workflow's audience and Fin's audience overlap for the same segment of customers, you end up with a race condition. Sometimes the workflow wins, sometimes Fin does, and it can look inconsistent even though the setup never changed. Going through your audience rules for both and making sure they're mutually exclusive, or that one clearly takes priority through step ordering, removes most of the unpredictability business owners report when they say Fin "sometimes works and sometimes doesn't."

How to Audit Your Setup

A practical way to find these issues before customers do is to walk through your own workflow as if you were a first-time visitor. Open the Messenger in preview mode, go through every button and path, and watch for three things: does the composer ever get disabled without being re-enabled, does any path end on a button without a follow-up prompt to type, and does any trigger fire on conditions broader than the first message. If you answer yes to any of those, that's where Fin is getting blocked, not because it's broken, but because the workflow never gave it an opening.

Getting the Order Right

Once the conflicts are cleared up, the actual sequencing is straightforward. Decide whether Fin or the workflow should see the conversation first, and build toward that intentionally rather than letting default triggers decide it. A common pattern that works well is using the workflow for structured intake, qualifying the request or collecting basic details, and then adding a "let Fin answer" step once the customer has typed something specific. That gives Fin real text to work with and keeps your workflow doing the job it's actually good at, which is directing traffic, not trying to answer open-ended questions itself.

Getting this sequencing right the first time saves a lot of back-and-forth troubleshooting later, and it's one of the most common things that goes unnoticed until resolution rates start looking off. If you're not sure whether your own workflows are quietly working against Fin, I help businesses audit and rebuild these setups so the two actually complement each other. Feel free to get in touch if you want a second pair of eyes on yours.

Cover photo by Kelly Sikkema on Unsplash.