Form

The Form node collects multiple structured inputs from the customer in a single turn. Each field captures into a recipe variable, and each field declares a classification that drives how the value is treated in audit logs.

Configuring the node

1. Drop the Form node from the Input & Collection category onto the canvas.
2. Open the configuration drawer:
   • Prompt — bilingual (English + Arabic). Shown above the form on the customer’s side.
   • Fields — add one or more in order. Each field has:
     • Key — snake_case identifier (e.g. dob, policy_number).
     • Type — Text, Number, Email, Phone, Date, Select (single), or Select (multi).
     • Target variable — the recipe variable that receives the value.
     • Classification — drives PHI / sensitivity handling:
       • A · PHI — protected health info (medical IDs, diagnoses). Redacted in audit logs.
       • B · Sensitive — personal data (name, email). Standard handling.
       • C · None — non-sensitive (preference, channel).
     • Options — required for Select / Multi-select; each option has a value and bilingual label.

Output ports

• submitted — the customer completed the form.
• fallback — the customer didn’t submit (e.g. cancelled or timed out).

Where it’s used

Use Form when you need to collect a small structured dataset in one step instead of stringing together multiple Question nodes — for example, an eligibility-check or pre-authorization intake.

Best practices

• Classify every field correctly. A misclassified PHI field can leak to audit logs in the clear.
• Keep forms short — 5 fields or fewer. Long forms suffer high abandonment on chat surfaces.
• Use Select fields wherever the answer set is bounded. Free-text fields require parsing and validation downstream.
• Localise option labels in both English and Arabic. The customer sees the bilingual one that matches the conversation language.