Typed Input

Category: Input & Collection

Overview

The Typed Input node prompts the customer for input and validates the reply against a typed schema before capturing it. Valid replies are written to the configured variable and flow through the valid port. Invalid replies trigger an optional validation message and flow through the invalid port, where you can loop back for a retry or branch to a fallback.

When to use

Collect numeric values (age, amount, quantity) with min/max range checks.
Capture an email or phone number in a strict format (E.164 for phone, RFC-5322-lite for email).
Accept dates in ISO format (YYYY-MM-DD) and reject ambiguous formats.
Validate against a custom regex (member IDs, internal codes) on top of any other type rule.
Require a URL with an http:// or https:// scheme.

Ports

Port	Direction	Description
`in`	input	Receives the flow from the previous node.
`valid`	output	Fires when the reply parses successfully and is captured to the configured variable.
`invalid`	output	Fires when the reply fails validation. The validation message (if configured) is sent first.
`fallback`	output	Optional legacy port. Only used if no `invalid` port is wired — keeps older recipes working.

Configuration

Typed Input config drawer showing the input-type selector and validation fields

Prompt (EN / AR)

The question shown to the customer. Both languages can be authored side-by-side; the runtime renders the one that matches the conversation’s active language.

Input type

The schema to validate against. One of:

text — any non-empty string (governed by min/max length below).
email — must match local@domain.tld shape, ≤254 characters.
phone — must be E.164 (+ followed by 7–14 digits, so total length 8–15 with the +).
date — must be ISO YYYY-MM-DD and parse to a real date.
number — must be a finite number; combined with the optional min/max range.
url — must be a valid URL with http:// or https:// scheme.

Capture to variable

Pick the scope (Recipe / Conversation / User) and the variable name. The parsed value is written into that variable when the reply is valid. See Variables for scope semantics.

Required

When on, blank replies are treated as invalid. When off, a blank reply is captured as an empty string and flows through valid.

Min / Max length (text only) and Min / Max (number only)

For the text type, the two numeric fields cap the string length. For the number type, they cap the numeric range. They have no effect for other types.

Regex (optional)

A JavaScript regular expression applied on top of the type rule. Anchors (^…$) are not added automatically — write the expression you actually mean.

Validation message (EN / AR)

Sent to the customer before the flow advances through invalid. Leave blank to advance silently.

Common patterns

Strict email capture with retry

Typed Input (type=email, var=customer_email). Wire invalid back to the same Typed Input — the runtime suppresses the cycle warning for this exact retry shape.

Number with range check

Typed Input (type=number, min=1, max=10, var=rating). Wire valid → Set Variable, invalid → Message (“Please enter 1–10”) → loop back.

Limits & validation

If neither valid nor invalid/fallback is wired, the runtime escalates with typed_input_missing_valid / typed_input_missing_invalid_and_fallback.
The publish validator suppresses the V17 cycle warning for invalid → self and fallback → self because it is the canonical retry-on-bad-input shape.

Troubleshooting

Valid input keeps falling to Invalid.

Test the regex against the customer’s actual reply in the Simulator. Common issue: missing anchors (^…$) make a partial match unintentionally fail other rules. Also verify the type rule — phone requires the leading +, date requires ISO format.