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 keyed message is {{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.