Overriding Fin's default "connect to human" prompt to check for existing issue context first

Question

Hi all,Looking for guidance on customizing Fin's default human handoff behavior (We use Fin over API).Right now, when a user asks for a human (Right from the first message), Fin responds with:"I understand you would like human support. Would you like me to connect you to a human agent? You can also continue working with me and provide more details if you prefer."We're building a multi-stage escalation flow (a short ladder of clarifying prompts before handoff) to collect 3 key infos for our support team (What customers were trying to do in the product, where are they in the product, what happened), but we need the final stage to first check whether the user already gave issue details earlier in the conversation, rather than asking for information a third time if they already provided it. I understand that Escalation Guidances are stateless so we can’t store anything in there. How can we build a robust support detail collection flow in case customer asked directly for human agents? i.e (Override First-turn escalation: The customer tries to escalate immediately after Fin introduces itself)Specifically:Is there a way to have Fin evaluate prior turns in the same session for issue-relevant content (a stated problem, an error message, a described task) before triggering the escalation prompt?	Can this check be configured as a condition within Workflows? (Should we create 3 different attributes for the 3 needed key infos?)	If it's API-side, is this something the session state payload could carry (a flag or summary passed in) rather than Fin needing to infer it from the raw conversation history each time?End goal: skip straight to handoff if the user already gave enough context earlier in the conversation, and only run the clarifying ladder if they genuinely haven't i.e When they ask for human support right from the start.Any pointers to relevant docs, existing setups, or people who've solved something similar would be great.Thanks!

marcusbear · Accepted Answer

Because you're already orchestrating Fin over API, I'd make the three-field check deterministic in your own session state.

For each turn, update three flags: intended task, product location, and observed failure. Seed them from the recent conversation turns you already pass into Fin, then ask only for fields that are still missing. When all three are present, call handoff.

I wouldn't use permanent contact attributes unless another Workflow needs them. These values describe one incident, not the person.

One edge case: let a correction replace prior state. "Actually, I was in Settings, not Billing" should update the location rather than count both. Also reset the flags when a new issue starts.

Fin's conversation metadata supports up to the last 10 prior messages:

https://developers.intercom.com/docs/references/rest-api/api.intercom.io/fin-agent/fin_agent_conversation_metadata

marcusbear · Answer

Since you're using Fin over API, I'd keep the deterministic check on your side rather than trying to make Escalation Guidance remember state.

The Fin Agent API accepts up to the last 10 messages as conversation metadata. Before each reply, scan those turns for the three fields, then keep explicit present/missing flags in your app's session state. If all three are present, hand off. If not, ask only for the missing fields.

I wouldn't create three Intercom attributes unless Workflows need them for routing or reporting. For one conversation, app-side flags are simpler and avoid stale contact data. Update the flags from both user turns and Fin's previous prompts, otherwise a partial answer can trigger the same question twice.

The relevant API field is documented here:

https://developers.intercom.com/docs/references/rest-api/api.intercom.io/fin-agent/fin_agent_conversation_metadata

Join the Intercom Community 🎉

Intercom Customers and Employees

Login to the community

Intercom Customers and Employees