Standard Module

The essential building blocks for every workflow collect input, send output, route decisions, normalize text, set variables, tag outcomes, call external APIs, delay, log, and raise errors.

The Standard Module provides the core Tasks that most workflows need. It includes I/O Tasks for collecting and sending messages, a routing Task for branching logic, language selection, string normalization, variable assignment, outcome tagging, generic HTTP, scheduled delays, audit-log checkpoints, and explicit error throwing. This Module is typically the first one installed in any Process. Its Environment configuration is optional you only need it to allow HttpTask access to specific internal hosts.

How it works

The Standard Module provides two kinds of Tasks. The I/O Tasks InputTask, OutputTask and EndTask are shared by every Channel: this Module ships their implementations for the Chat Channel, while Modules like Twilio Messaging, Twilio Conversations, Twilio Voice, Aculab, and ACS provide implementations of the same Tasks for messaging and telephony Channels. Starts are the exception: each Channel that starts Sessions has its own start, from the Module that receives it, and this Module's StartTask is the Chat / API start. The logic Tasks SwitchTask, LanguageTask, StringNormalizationTask, SetVariableTask, SetTagTask, HttpTask, DelayTask, LogTask, and ThrowErrorTask are generic and work identically on every Channel.

Data moves through a Process as Session variables named values stored in the running Session, written by one Task and readable by later Tasks as {name}. A typical turn collects a message with InputTask, transforms or evaluates it with logic Tasks, and replies with OutputTask.

Configuration

The Standard Module's Environment configuration is optional. It controls which internal hosts HttpTask may reach and where the files your flows receive and create are kept. Set it in the Module's Environment configuration: each Environment keeps its own values.

Allowed Internal Hosts

Hostnames or IP literals (exact match, case-insensitive) that HttpTask is permitted to call even when they resolve to a loopback / private / link-local address. Default: empty every internal address is blocked.

Field	Type	Required	Description
Allowed Internal Hosts	list of string	No	Exact hostnames (admin.internal) or IP literals (10.0.1.5). No wildcards, no CIDR. Default: empty.

Add only the few internal endpoints your workflows legitimately need to reach. Entries that are neither valid hostnames nor IP literals are ignored.

File storage

Where the files of this Environment's flows are kept: email attachments, files sent in the chat, files made by Create file.

Value	Description
Workspace storage (reference)	Default. The bytes go to the workspace's storage for 90 days and count toward its storage quota; the variable holds a reference.
Inline in the variable	The bytes stay in the variable itself (base64), up to 2 MB per file; a larger file still goes to workspace storage. No storage is used, but every step of the Session carries the files.

Limits

• An HTTP request times out after at most 300 seconds, and a response body is rejected above 10 MB (the configurable per-Task values are capped at these ceilings).
• HttpTask follows at most 5 redirects per request.
• StringNormalizationTask rejects inputs longer than 1,000,000 characters and pipelines with more than 50 steps; a single regex match stops after 250 ms.
• SetVariableTask accepts at most 50 assignments per Task; each assigned value is capped at 64 KB.
• SetTagTask tags are capped at 100 characters; longer values are cut.
• LogTask messages are truncated at 4,000 characters with a …(truncated) marker.
• DelayTask pauses are capped at 86,400 seconds (one day).
• A chat message carries at most 5 files and 10 MB in total; an OutputTask sends at most 10 files and 15 MB; Create file makes files up to 15 MB.

Tasks

InputTask (Channel: Chat)

Collects a message from the end user and stores it in the Session.

Properties

Property	Type	Required	Example	Description
Prompt Message	string	No	What is your name?	Message sent to the user before waiting for input. Supports {variable} placeholders. Default: empty (no prompt).
Store result in	string	Yes	{userName}	Store variable write it in braces ({userName}); the Task saves the user's reply there and later Tasks read it back with the same {userName} reference.
Store files in	string	No	{uploads}	The files the user sent with the reply (paperclip in the chat): {uploads.count}, {uploads.names}, {uploads.0} (a file for Read file or an Output's Attachments).

Behavior

1. The Task sends the Prompt Message (if set) to the user.
2. The Token pauses at this node and the Session waits.
3. The next user message resumes the Token; the message text is written to the store variable.

Example

Prompt Message What is your name?, Store result in {userName}. The Session asks the question and waits. The user replies Maria; the Token resumes and {userName} now holds Maria, ready for a later OutputTask to greet the user with Hello {userName}!.

OutputTask (Channel: Chat)

Sends a message to the end user.

Properties

Property	Type	Required	Example	Description
Output Message	string	Yes	Hello {userName}, your request is complete.	The text to send to the user. Supports {variable} placeholders for dynamic values.
Attachments	file field	No	ref-session:{report}, ref-storage:terms.pdf	Files sent with the message, separated by commas: Session files (ref-session:{uploads} for a list) or saved files (ref-storage:, ref-workspace:). See File fields. The chat shows them as downloads; Gmail attaches them; voice Channels send only the text.

Behavior

1. The Task resolves every {variable} placeholder against the current Session variables.
2. It sends the resulting text to the end user on the active Channel.

Example

Output Message Your order {orderId} has shipped. with {orderId} = A-1042 sends Your order A-1042 has shipped. to the chat user, and the Token immediately continues to the next node.

StartTask (Chat / API start)

The start of Sessions from the web chat, and of runs started by the API, an AI assistant or a schedule. It is the default Start Event: a Start Event dropped from the palette becomes a StartTask.

Properties

Property	Type	Required	Example	Description
Chat variable	string	No	{chat}	The variable that receives who started the chat: {chat.from}, {chat.to}, {chat.channel} and {chat.isTest}. Default: {chat}. Runs started by the API or a schedule keep their data as top-level variables.
Inputs	list	No	customerId (text, required), reportMonth (month, default: the month before the run's time)	The values a run can receive when it starts, see Inputs.

Inputs

Each input is one variable the run starts with:

Field	Description
Variable	The variable the value is stored in, e.g. customerId. A schedule or an API call sends it under this name.
Label	How the schedule's data form names the input.
Type	Text, Number, Yes / no, Date (yyyy-mm-dd), Date and time, Month (yyyy-mm), Choice (with its Choices) or JSON. A value sent as text is converted: "12" becomes the number 12, "yes" becomes true.
Required	A run without a value, and without a default, stops at the start with error 8026.
Default	No default, A value (the Default value), or From the run's time for dates and months: the day before, the same day or the day after, the month before, the same month or the month after, or the run's time itself.
Help	Optional text shown under the field on the schedule's data form.

The run's time is the planned time of a scheduled run (also when it runs late, after a downtime), otherwise the time it starts. A schedule's dates and months are read in its time zone, other runs in UTC: a monthly report planned for 1 November 07:00, Rome time, with Report month = the month before gets 2026-10.

A value the run sends always wins over the default. A value that doesn't fit the type, or is not one of the choices, stops the run with error 8027. On the chat, where you test the flow without sending data, both are only warnings in the Session's log.

The Scheduled tasks page builds a schedule's data form from these inputs, and refuses to save a schedule that misses a required one. When a newer version adds a required input with no default, the schedules that don't send it show as Held: missing data until you give the input a default or the schedule a value.

Behavior

1. A user opens the chat and the Session starts on the Chat Channel, at this start.
2. The StartTask writes the {chat} variable, gives every input its value (the one sent, else its default) and passes the Token to the first connected node. A run started by a schedule, the API or the assistant starts here too, with its data.

Several Channels in one Process

A Process answers each Channel at that Channel's own start: add one Start Event per Channel and pick its start in the replace menu (each start lists the Channels it serves), for example the StartTask for the chat and a call start for the phone. Connect every start to the first step they share; Input, Output and End Tasks work on every Channel. Each start writes its own variable ({chat}, {call}, {message}, ...), all with from, to, channel and isTest. Keep one start per Channel: two starts serving the same Channel stop the Session with error 8024.

The StartTask still runs the messaging and telephony Channels of Processes built before those Channels had their own start. When such a Channel's Module has its own start, the StartTask's settings show a warning with a Replace button that turns it into that start (same id, name and Sequence Flows).

Example

A visitor sends their first message to your deployed Process. A new Session starts, the StartTask writes {chat}, and the Token moves along the outgoing Sequence Flow, typically to an OutputTask that greets the visitor. A monthly report flow declares customerId (required) and reportMonth (month, the month before the run's time): its schedule only sends customerId, and every run gets the previous month.

EndTask (Channel: Chat)

Closes the Session on the Chat Channel.

Properties

The EndTask has no properties.

Behavior

The Session is marked as completed. The EndTask sends nothing: to say goodbye, place an OutputTask with the closing text right before the End Event.

Example

OutputTask Message Thanks {userName}, have a great day! followed by the End Event: with {userName} = Maria the user reads Thanks Maria, have a great day! and the Session ends.

Create file (Generic)

Creates a file from text or from a document template, for an OutputTask's Attachments on any Channel.

Properties

Property	Type	Required	Example	Description
Save as	file field	Yes	ref-session:report.html	Where the new file goes and its name: ref-session: (a file of this Session) or ref-storage: / ref-workspace: (a saved file on the Storage page). The extension sets the type unless File type is set. Supports {variable}. See File fields.
When the saved file exists	choice	No	Replace	For ref-storage: only: replace it, or keep it (error).
Content from	choice	No	Text	Text (default) or A document template from Storage → Templates.
Content	string	With Text	{reportHtml}	The file's text, usually one variable an earlier step built. CSV files get a UTF-8 BOM so Excel shows accents.
Document template	string	With template	interactive-data-report.html	An HTML template filled with the flow's {variables} (HTML-encoded).
Data file	file field	No	ref-session:{result}	With a template: a file whose text fills the template's {data} placeholder ({data.name}: its name), read straight from storage, HTML-encoded and never copied into a variable. Typical source: a File Query result. Put {data} in a hidden <textarea> and read it from the page's script.
File type	string	No	text/html	MIME type. Empty: from the extension.
Store result in	string	Yes	{report}	Receives the file: {report.name}, {report.type}, {report.size}.

With a Data file the rows never enter the Session: File Query writes them to a file, Create file pours that file into the template, and the variables hold only references. Inside a template that uses a Data file, {data} and {data.name} always mean the file; the file's text is not scanned for {placeholders}.

Read file (Generic)

Reads a file (an email attachment, a chat upload, a created file) into a variable.

Properties

Property	Type	Required	Example	Description
File	file field	Yes	ref-session:{email.attachments.0}	One file: a Session file or a saved file (ref-storage:notes.txt). See File fields.
Read as	choice	No	Text	Text decodes it (UTF-8, UTF-16 with a BOM, else Latin-1 for older Excel CSV exports); Base64 and Data URL keep the bytes.
Store result in	string	Yes	{csv}	Receives the content as a string.

A file that was too large to keep, whose storage expired (90 days), or a saved file that does not exist, takes the error branch.

SwitchTask (Generic)

Routes the Token down one of several branches based on a Session variable. Works on all Channels.

Cases are evaluated top-to-bottom; the first matching case wins. When nothing matches, the Token is routed to the Default branch (ok if left blank). Multiple cases that share a Branch name act as an implicit OR. In the Process Editor, SwitchTask is placed as an Exclusive Gateway, and each Branch name must match the label of an outgoing Sequence Flow.

In the task panel, Go to and When nothing matches offer the node's outgoing flows. A case that names a flow the node does not have is marked red. Under the cases, Outgoing flows lists every flow of the node with what routes there (valid · 1 case, invalid · when nothing matches, support · no case routes here), so a flow nothing reaches stands out.

Properties

Property	Type	Required	Example	Description
Value to check	string	Yes	{userChoice}	The value the cases test, usually one Session variable (written as {name}).
Cases	list of cases	Yes	—	Comparison rules, evaluated top-to-bottom; the first match wins.
When nothing matches	string	No	other	Outgoing flow taken when no case matches. Default: ok.

Each case:

Property	Type	Required	Example	Description
Test	string	No	contains	How to compare: equals, contains, matches regex, greater than, or less than (stored as Equals, Contains, Regex, >, <). Default: equals.
Value	string	Yes	book	What to compare against. Supports {variable} placeholders.
Go to	string	Yes	booking	Outgoing flow to take when this case matches; must match an outgoing Sequence Flow label.
Ignore case	boolean	No	checked	When on, text comparisons (Equals, Contains) ignore letter case. Default: off (comparisons are case-sensitive).

Text comparisons (Equals, Contains) match exactly as typed unless the case's Ignore case toggle is on. When both sides are numbers, Equals, >, and < compare numerically (so 10 > 2 is true).

Behavior

1. The Task reads the Value to check from the Session.
2. It checks each case in order; the first case whose comparison succeeds selects its Go to flow.
3. If no case matches, the When nothing matches flow is selected.
4. The Token follows the outgoing Sequence Flow whose label matches the selected branch.

Example

Route a customer-service conversation on {userChoice}:

1. Variable to evaluate = {userChoice}.
2. Case 1: Op Contains, Value book, Branch booking.
3. Case 2: Op Contains, Value cancel, Branch cancel.
4. Default branch = other.

When the user types I'd like to book a table, case 1 matches and the Token follows the Sequence Flow labeled booking.

LanguageTask (Generic)

Sets the conversation language used by downstream Tasks that support localization. Works on all Channels.

Properties

Property	Type	Required	Example	Description
Language (RFC 5646 tag)	string	Yes	it-IT	Language/region tag, e.g. en-US, it-IT. Supports {variable} placeholders. The value must be a valid RFC 5646 tag.

Behavior

1. The Task resolves the Language value (including any {variable} placeholder).
2. It validates the tag and sets it as the Session's conversation language.
3. Downstream Tasks with locale-aware behavior use it as their automatic fallback.

Example

Language it-IT early in the Process makes later locale-aware Tasks for example the Date Module's Extract Date with Operation Format text render output in Italian (25 dicembre 2026) without setting a Locale on each Task individually.

StringNormalizationTask (Generic)

Transforms a string variable through an ordered pipeline of operations. Works on all Channels.

Properties

Property	Type	Required	Example	Description
Text to clean	string	Yes	{userInput}	The text to normalize, usually one Session variable (written as {name}).
Steps	list of steps	Yes	—	Up to 50 operations, applied in order.
Store the result in	string	Yes	{cleanInput}	Store variable write it in braces ({cleanInput}); the Task saves the transformed result there and later Tasks read it back as {cleanInput}.

Each step:

Property	Type	Required	Example	Description
Step	string	Yes	Replace regex	One of: Trim, Lower case, Upper case, Remove accents, Replace text, Replace regex (stored as Trim, ToLower, ToUpper, RemoveDiacritics, ReplaceText, ReplaceRegex).
Find text	string	Yes for ReplaceText	Mr.	Shown when Operation is ReplaceText. Substring to find. Supports {variable} placeholders. Must be non-empty.
Replace with	string	No	Mister	Shown when Operation is ReplaceText. Replacement text. Supports {variable} placeholders. Default: empty (removes the found text).
Regex pattern	string	Yes for ReplaceRegex	\s+	Shown when Operation is ReplaceRegex. .NET regular expression; the form validates the pattern as you type and offers presets.
Replace match with	string	No		Shown when Operation is ReplaceRegex. Replacement string; substitutions like $1, $2, ${name} are honored. Supports {variable} placeholders. Default: empty (removes the match).

Behavior

1. The Task reads the Text to clean from the Session.
2. It applies every step in order, each step receiving the previous step's output.
3. It writes the final result to the Store the result in variable.

Example

Text to clean {rawName}, Store the result in {cleanName}, Steps: Trim → Remove accents → Lower case. With {rawName} = " José ", the result {cleanName} is "jose" ready for a reliable SwitchTask comparison.

warning

Inputs longer than 1,000,000 characters are rejected with error 3005 (TaskInvalidData), and a regex step that takes longer than 250 ms to match is stopped. Keep patterns simple.

SetVariableTask (Generic)

Assigns or deletes one or more Session variables composition, copying, or cleanup without writing a script. Works on all Channels.

Properties

Property	Type	Required	Example	Description
Assignments	list of assignments	Yes	—	Up to 50 rows, evaluated top-to-bottom.

Each assignment:

Property	Type	Required	Example	Description
Variable	string	Yes	{fullName}	Store variable write it in braces ({fullName}); later Tasks read it back as {fullName}.
Action	string	No	Set to	Set to writes Value into Variable; Delete removes Variable from the Session (Value is hidden and ignored). Default: Set to.
Value	string	No	{firstName} {lastName}	Used only when Action is Set to. Supports {variable} placeholders, including variables set in earlier rows. Capped at 64 KB.

Behavior

1. Rows are evaluated top-to-bottom; later rows can reference variables set in earlier rows.
2. Set resolves the Value's placeholders and writes the result into the Variable.
3. Delete removes the Variable from the Session; deleting an absent variable is harmless.
4. An unrecognized Action is treated as Set and a warning is written to the audit log.

Example

Compose a full name, then drop the secret used to fetch it:

Variable	Action	Value
{fullName}	Set to	{firstName} {lastName}
{apiKey}	Delete

With {firstName} = Maria and {lastName} = Rossi, the Task sets {fullName} to Maria Rossi and removes {apiKey} from the Session.

SetTagTask (Generic)

Labels the execution with one outcome tag, such as resolved, escalated, or abandoned, so you can see how your runs end. The Dashboard charts executions by tag (switch its Channels card to Tags), and the Sessions list shows each execution's tag and filters by it. Works on all Channels.

Properties

Property	Type	Required	Example	Description
Tag	string	Yes	resolved or intent:{intent}	The execution's outcome label. Supports {variable} placeholders. Capped at 100 characters.

Behavior

1. The Task resolves the Tag's {variable} placeholders, turns line breaks and runs of spaces into single spaces, and trims the ends.
2. It sets the result as the execution's tag. An execution has one tag: a later SetTagTask replaces it, so the last one reached wins.
3. If the Tag resolves to nothing (for example, a variable that isn't set), the current tag is kept and a warning is written to the audit log.
4. Tags starting with __ are reserved for the platform: the current tag is kept and a warning is written to the audit log.
5. A tag longer than 100 characters is cut to 100 and a warning is written to the audit log.
6. None of these warnings stop the Token or mark the execution as failed: a tag is reporting data, never a reason to fail a run.

The tag is saved each time the execution completes or pauses, so a tag set just before a long wait already shows while the execution waits.

Example

Place SetTagTask with Tag resolved just before the End Event of your happy path, and another with Tag escalated on the branch that hands the conversation to an agent. The Dashboard's Tags view then shows how many executions in the billing period ended each way, plus the ones that never reached either Task as Untagged.

HttpTask (Generic)

Calls a URL and keeps the response in a variable: status, headers and body. Variables in the URL, headers and body are filled in when the step runs. Works on all Channels.

Properties

Property	Type	Required	Example	Description
URL	string	Yes	https://api.example.com/users/{userId}	Absolute URL. Supports {variable} placeholders. Substituted values are not URL-encoded avoid variables containing /, ?, &, or #, or encode them first with the JavaScript Module.
Method	string	Yes	POST	One of: GET, POST, PUT, PATCH, DELETE. Default: GET.
Timeout	duration	No	30 s	Advanced. Per-request timeout including reading the response body, stored in seconds. Range 1 s to 5 min. Default: 60 s.
Max response	integer (KB)	No	1024	Advanced. Reject responses whose (decompressed) body exceeds this size, in KB. Range 1–10240. Default: 4096 (4 MB).
Store response in	string (object)	Yes	{response}	Store variable write it in braces ({response}); the Task saves the response object { Status, Body, Headers, FinalUrl } there.
Headers	list of headers	No	Authorization / Bearer {apiKey}	Each row has a Name and a Value; both support {variable} placeholders. Set Content-Type here for requests with a body.
Body	string	No	{"name": "{userName}"}	Request body, edited in the Headers box. Shown for POST, PUT, PATCH, and DELETE (hidden when Method is GET). Supports {variable} placeholders (type { in the editor). The JSON / XML / Text picker only changes highlighting and Format (which keeps placeholders); the body is sent as typed, so set Content-Type in Headers.

Behavior

1. The Task resolves {variable} placeholders in the URL, headers, and body.
2. It validates the destination against the internal-address protection (see below).
3. It sends the request and follows up to 5 redirects, re-checking each hop's destination; the Authorization header is dropped when a redirect leaves the original site.
4. It writes the response object to the Output Variable: Status (number), Body (text), Headers (name/value map), and FinalUrl the URL the response actually came from, after any redirects.
5. On a non-2xx status, the Task output is set to error and an audit-log entry is added; an Exclusive Gateway after the Task can route on it.
6. On timeout, connection failure, redirect loop, or an oversized body, the Task output is set to error and the cause is logged.

Internal-address protection

By default, HttpTask refuses to call any address that resolves to a loopback, private-network, link-local, or cloud-metadata destination for example localhost, 127.0.0.1, 10.x.x.x, 192.168.x.x, or 169.254.169.254. The check applies to the address the hostname actually resolves to, on every redirect hop, and fails closed when the name cannot be resolved.

To allow specific internal endpoints, list them in the Module's Environment configuration under Allowed Internal Hosts. Entries must be exact hostnames or IPs no wildcards, no CIDR.

Reserved headers

The following request headers cannot be set from a Task: Host, Content-Length, Transfer-Encoding, Connection, Upgrade, Expect. A header containing a line break is rejected.

Example

URL:             https://api.example.com/users/{userId}
Method:          GET
Output Variable: {response}

With {userId} = 42, the Task calls https://api.example.com/users/42. After execution, {response.Status} is 200, {response.Body} holds the returned JSON text, and {response.FinalUrl} shows the URL the response came from after any redirects.

DelayTask (Generic)

Pauses the workflow for a fixed duration. Works on all Channels. In the Process Editor, DelayTask is placed as an Intermediate Catch Event.

Properties

Property	Type	Required	Example	Description
Wait for	duration	Yes	5 min	How long to pause before resuming, stored in seconds. Range 1 s to 1 day. Default: 5 s.

Behavior

1. The Token suspends at this node.
2. The platform resumes the Token automatically once the configured duration has elapsed.
3. If the wake-up cannot be scheduled, the Task stops the Token and writes an explicit audit-log entry rather than leaving the workflow hanging.

Example

Wait for 5 min between an OutputTask (We're checking your request…) and a follow-up HttpTask polls the external system five minutes later, without the user having to do anything.

LogTask (Generic)

Writes an explicit checkpoint to the audit log a debug breadcrumb without writing a script. Works on all Channels.

Properties

Property	Type	Required	Example	Description
Severity	string	Yes	Warning	Info = audit-only breadcrumb. Warning = audit entry + flag the Session as exceptional (execution continues). Error = audit entry + stop the Token. Default: Info.
Message	string	Yes	Reached checkpoint X with userId={userId}	Message to write. Supports {variable} placeholders. Truncated at 4,000 characters with a …(truncated) marker.

Behavior

1. The Task resolves the Message's {variable} placeholders.
2. It writes the message to the Session's audit log at the chosen Severity.
3. Info and Warning let the Token continue; Error stops it.

Example

Severity Info, Message Order lookup done for {orderId}. With {orderId} = A-1042, the entry Order lookup done for A-1042 appears in the Session's audit log on the Sessions page, and the Token continues unchanged.

ThrowErrorTask (Generic)

Raises a workflow error with a custom message halt outright, or route a controlled failure path. Works on all Channels. In the Process Editor, ThrowErrorTask is placed as an Intermediate Throw Event.

Properties

Property	Type	Required	Example	Description
Mode	string	Yes	Branch	Stop halts the workflow. Branch marks the Task output as error so a downstream Exclusive Gateway can route to the error path. Default: Stop.
Message	string	Yes	Plan limit exceeded for {workspaceId}	Error message written to the audit log. Supports {variable} placeholders.

Behavior

1. The Task resolves the Message's {variable} placeholders and writes it to the audit log.
2. With Mode Stop, the Token halts and the Session is marked as failed.
3. With Mode Branch, the Token continues along the outgoing Sequence Flow labeled error.

Example

Mode Branch, Message Inventory check failed for {sku}. When a prior lookup leaves {sku} = SKU-991, the error is logged and the Token follows the error Sequence Flow to an OutputTask that apologizes to the user instead of crashing the Session.

Common recipes

Route a chat conversation by user intent

Ask the user what they need, normalize the reply, and branch to the right answer.

1. InputTask Prompt Message How can I help you today?, Store result in {userChoice}.
2. StringNormalizationTask Input Variable {userChoice}, Output Variable {intent}, Steps: Trim → RemoveDiacritics → ToLower. This makes the comparison immune to stray spaces, accents, and capitalization.
3. SwitchTask Variable to evaluate {intent}; Case: Op Contains, Value book, Branch booking; Default branch other. Label the outgoing Sequence Flows booking and other.
4. OutputTask (booking branch) Output Message Great let's get your booking started.
5. OutputTask (other branch) Output Message I can help with bookings. Could you rephrase your request?

Call an external API and report the result

Fetch data over HTTP, branch on the response status, and reply with either the result or an apology.

1. HttpTask URL https://api.example.com/orders/{orderId}, Method GET, Output Variable {response}.
2. SwitchTask Variable to evaluate {response.Status}; Case: Op <, Value 300, Branch success; Default branch error. Label the outgoing Sequence Flows success and error.
3. SetVariableTask (success branch) one assignment: Variable {summary}, Mode Set, Value Order status: {response.Body}.
4. OutputTask (success branch) Output Message {summary}.
5. OutputTask (error branch) Output Message Sorry, we couldn't reach the order system. Please try again later.

Best practices

1. Always pair Input with Output a typical conversation turn is an OutputTask (prompt) or an InputTask Prompt Message, followed by reading the reply.
2. Use SwitchTask for routing, not complex logic for deeply nested conditions, use the JavaScript Module.
3. Normalize early apply StringNormalizationTask right after collecting user input so downstream comparisons see consistent data.
4. Prefer SetVariableTask over scripts for trivial composition it's faster, audited, and easier for non-developers to read. Use Mode Delete to scrub sensitive variables (API keys, tokens) from the Session once you're done with them.
5. Keep Allowed Internal Hosts minimal every entry weakens the internal-address protection. Add only the exact hostnames or IPs your workflows need, and review the list whenever you add a new HttpTask integration.
6. Use ThrowErrorTask intentionally it marks the Session as failed in the audit view; reserve Stop for unrecoverable conditions and Branch for controlled fallback paths.
7. Compare numbers as numbers SwitchTask's > and < compare numerically when both sides are numbers (so 10 > 2 is true). Text comparisons are case-sensitive by default; turn on a case's Case-insensitive toggle to ignore letter case.
8. Keep delays purposeful prefer short DelayTask pauses for polling or pacing; for long waits or recurring schedules, start the workflow on a schedule instead with the Scheduler Module.
9. Tag with a small, stable set of outcomes tags are for counting how runs end, so use a handful of values (resolved, escalated, abandoned) and build them from variables only when the variable has few possible values, like an intent. Never tag with ids, phone numbers, or e-mail addresses: every run would get its own tag and the Dashboard chart would say nothing.

Error codes

Code	Name	Description
3005	TaskInvalidData	See full details
4001	ModuleException	See full details
4009	ModuleInputEmpty	See full details
4012	ModuleInvalidData	See full details
4013	ModuleLog	See full details
4022	ModuleLogWarning	See full details