Hosted chat
Use whenA user needs a multi-turn conversation, follow-up questions, or visible answer history.
VerifyIdentity, session continuity, citations, attachments, feedback, reset, and escalation.
Interface launch · Updated August 25, 2026
The workflow is not the product.
The user path is.
A working agent can still fail at access, files, sessions, embeds, error states, or release. Choose the surface by the user's job, then test one complete path from first visit to rollback.
Commercial disclosure: if our referral link is active and you later buy an eligible paid Falcon Builder plan through it, we may earn a commission. This launch checklist is independently useful without that link.
Decision one
Choose the surface by the job.
Do not begin with a feature list. Begin with the interaction the user must complete and the evidence that proves it worked.
Structured form
Use whenThe task needs known fields, repeatable validation, and one bounded submission.
VerifyRequired fields, file rules, confirmation, duplicate submit behavior, and result delivery.
Website embed
Use whenThe experience must live inside an existing product, help center, or marketing site.
VerifyAllowed origins, frame policy, responsive layout, host-page events, and failure isolation.
Messaging
Use whenThe user already works in SMS or WhatsApp and expects an ongoing thread.
VerifyProvider dependency, contact identity, media handling, opt-out, delivery failure, and handoff.
Decision two
Climb the access ladder only as far as the risk requires.
01
Public
Anyone with the URL can open it. Use only when the data and action are safe for anonymous traffic.
02
Shared password
A single secret creates a lightweight gate, but does not identify which person used it.
03
Email OTP / allowlist
An address proves access to an inbox and can bind a conversation to one permitted identity.
04
Workspace identity
Existing organization membership controls access and should inherit current removal rules.
05
SSO / OIDC
Central identity and lifecycle control for environments that have verified plan and setup support.
Input contract
Write the upload rules before accepting a file.
“Supports documents” is not a testable requirement. Type, size, validation, storage, and processing must agree at every boundary.
Allowed types
List each accepted text, image, PDF, or document format. Reject everything else.
Size limit
State limits before upload and test both the browser and processing boundary.
Validation
Check extension, MIME type, structure, required fields, and empty or corrupt content.
Malware handling
Define scanning, quarantine, rejection, and what reaches downstream tools.
Retention
State where input, extracted text, and model context remain—and for how long.
Model compatibility
Verify that the chosen model and workflow can actually process each allowed input.
Session contract
Know who returns to which conversation.
Identity, memory, and history are separate choices. Test anonymous and authenticated paths independently.
Session ID
Choose the stable key that joins turns without merging two people.
Authenticated user
Bind identity at the interface, not from a name typed into a prompt.
Multi-device history
Decide whether a verified user resumes the same conversation elsewhere.
Reset and deletion
Give the user and operator an explicit way to start over or remove stored history.
Failure UX
Make every broken path visible and recoverable.
A user needs an honest state, a next action, and protection from duplicate effects—not a generic “something went wrong.”
Timeout
Hold the downstream response past the interface limit. Show a useful state and a safe retry.
Partial output
Interrupt a streamed answer. Mark it incomplete instead of presenting it as final.
Invalid file
Submit an unsupported, empty, renamed, or corrupt file and explain what was rejected.
Lost session
Expire or clear the session between turns. Do not silently attach the user to another thread.
Upstream outage
Disable the model or integration and preserve the user input without inventing success.
Human escalation
Trigger the handoff path and verify the person receives the required context.
Release control
Move one reviewed version through four states.
Draft
Change the workflow and interface without touching the live user path.
Test URL
Run representative users, devices, files, failures, and access states against the draft.
Publish
Promote one reviewed version and record what changed, who approved it, and when.
Rollback
Restore a known version and confirm sessions, embeds, and integrations recover as expected.
One complete-path launch test
Test the journey, not isolated screens.
Use harmless data and one representative task. Keep the acceptance evidence together.
- 01
Start with a new user. Enter through the real URL and complete the intended access step.
- 02
Submit the hardest valid input. Include the largest allowed file and all required fields.
- 03
Continue the session. Ask a follow-up that depends on prior context.
- 04
Repeat on a second device. Confirm the expected identity and history behavior.
- 05
Force one failure. Recover without duplicate processing or a false success state.
- 06
Publish and roll back. Prove the tested version can go live and a known version can return.
Falcon-specific checkpoint
Use current product claims as demo prompts, not assumptions.
Falcon Builder's current homepage describes hosted chat, forms, a website chatbot, and WhatsApp/SMS. It also labels public, password, email + OTP, workspace login, and SSO/OIDC as access modes, and describes image, PDF, and document attachments. Verify the exact interface, input limit, and plan in the live product before committing.
The current MCP documentation describes password-protected or email-allowlist interfaces, per-workspace identity, embed-origin restrictions, draft editing, runs that may create real side effects, and separate publish/rollback permission. Those details are useful evaluation targets; they do not prove that every interface, plan, file, device, or integration behaves identically.
Current pricing marks some enterprise controls as “Coming soon.” Falcon's Terms do not promise uninterrupted, secure, error-free, accurate, or reliable service. Keep launch acceptance criteria specific to the chosen configuration.
Primary sources