End-User Interfaces
Turn any workflow into a product your users can interact with — a hosted form, a chat assistant, or an embeddable website chatbot — each with its own public URL and access controls.
Interface types
- Form — structured input collection. Each field becomes an input; the user submits once and sees a single result. Best for fixed inputs (e.g. “paste a resume + job description → get a cover letter”).
- Chat Assistant — open-ended, multi-turn conversation with streaming responses and (for signed-in users) cross-device history. Best when the conversation itself drives the workflow.
- Website Chatbot — the Chat Assistant rendered as a floating bubble you embed on any site with a one-line script tag.
Publishing an interface
- Open your agent (Dashboard → Agents → your agent).
- In the Interfaces section, click New Interface, choose Form or Chat, and pick the workflow it binds to. (An agent can publish several — one per workflow.)
- Click Deploy to get a public URL (
/i/<slug>), and use the ⚙️ gear to customize the title, brand color, logo, welcome text, fields, and chat behavior. - For a website chatbot, copy the embed snippet (the </> icon) and paste it on your site.
How a Form-backed workflow must be built
A form is one-shot: submit fields → run once → show a single result. Build the bound workflow as:
Webhook Trigger → AI Prompt → Webhook Response
- Webhook Trigger is the entry point (the form posts here).
- Each form field is read in the workflow as
{{input.<fieldKey>}}— e.g. a field keyedmessageis{{input.message}}. - The Webhook Response node's body is exactly what the form displays — e.g.
{{ai_response.response}}. - Use AI Prompt (single-shot), not Agent Loop, for forms. AI Prompt is fast and deterministic; an Agent Loop with web-search tools can take 30–60s and exceed the request timeout (a form waits for the whole run).
- The agent and the workflow must both be active.
Quick test: Webhook Trigger → Webhook Response with body { "result": "Received: {{input.message}}" } proves the form wiring with no LLM, then add an AI Prompt in the middle.
How a Chat-backed workflow must be built
Webhook Trigger → Agent Loop → Webhook Response
- The responder (Agent Loop or AI Prompt) reads the user message from
{{input.message}}(or whatever you set as the message input key). - Return the reply via a Webhook Response (e.g.
{{agent_result.response}}) or the final node output. - For multi-turn memory, set the responder's Conversation ID to
{{input.sessionId}}. The chat supplies a fresh session per conversation, so each “New chat” is distinct. - Chat responses stream token-by-token when the responder is a no-tool Agent Loop; tool-using agents reply once the run completes.
Form vs Chat — which to use
- Form — a fixed set of inputs and one deterministic result. Fast, single-pass workflows (summarize, classify, generate, create a record).
- Chat — back-and-forth, agents that use tools/knowledge, or anything that benefits from streaming and conversation history.
Access control
Each interface has an access mode (set in the Interfaces panel):
- Public — anyone with the link.
- Password — a shared password gate.
- Workspace members — signed-in Falcon users who have access to the agent.
- Email allow-list — named external people verify via a one-time emailed code (no workspace seat consumed).
- SSO (OIDC) — sign in through your identity provider.
For signed-in modes (Workspace / Email / SSO), chat history is stored server-side and follows the user across devices. Public and password chats keep history in the browser.
Embedding a website chatbot
Paste the snippet from the Interfaces panel before your site's closing body tag:
<script src="https://YOUR_APP/embed.js"
data-falcon-slug="your-interface-slug"
data-color="#6d28d9"></script>Optional: restrict which domains may load the widget with the allowed domains setting.