Task Configuration

Configure the data and behavior of every Task node directly from the editor's side panel.

When you click a Task in the BPMN Editor, a configuration panel opens on the right side of the screen. This panel displays the properties defined by the Task's Module type and lets you set the values that control what the Task does at runtime.

How it works

Each Task in the editor has two key attributes stored in the BPMN XML:

• type identifies which Module Task this node represents (e.g., InputTask, SwitchTask, JSTask). Set automatically when you convert a generic Task via the replace menu.
• data a JSON object containing the Task's configured properties. Updated through the side panel form.

When the Token reaches a Task during execution, the engine reads the type to determine which Module handler to invoke and passes the data as the Task's configuration.

Using the side panel

1. Click any Task on the canvas to select it.
2. The side panel opens on the right, showing a form with the Task's properties.
3. Fill in or modify the property values.
4. Click Save Changes at the bottom of the panel to apply your edits to the node.
5. Click Save in the toolbar to persist the entire Process (including all Task data) as a new version.

tip

If the side panel shows no properties, the Task may still be a generic Task. Right-click it and use the replace menu to convert it to a specific Module Task type.

Property types

Task properties use different input controls depending on their data type:

Control	Description
Text field	A single-line string input for names, variables, or short values.
Text area	A multi-line input for longer text such as messages or prompts.
Dropdown	A selection from predefined options (e.g., comparator types, languages).
Code editor	A syntax-highlighted editor for writing code (e.g., JavaScript scripts).
List	A repeatable group of fields for configuring multiple items (e.g., normalization steps, switch outputs).
Boolean	A toggle for true/false settings.

Variable references

Many Task properties accept variable references names that correspond to Session variables set by previous Tasks. Variable names are case-sensitive.

For example, if an OutputTask sets a message using a variable called userName, a previous Task in the workflow must have written a value to userName in the Session data.

warning

If a referenced variable does not exist in the Session at runtime, the {placeholder} resolves to an empty string the Task does not fail, the value is simply missing. Double-check that variable names match exactly between Tasks (they are case-sensitive).

Values from users are untrusted

A variable filled by a Session's user or by another system (a chat or SMS message, an inbound email, a form field, an uploaded file, an HTTP response) holds whatever they sent, and a {placeholder} puts it in as it is. EW-Flow does not mark or clean it, so design for hostile text:

• URLs and headers. A value placed in a URL is not URL-encoded: a /, ?, & or # in it changes the address. Encode it first (for example encodeURIComponent in the JavaScript Module), and keep user text out of request headers.
• Request bodies. An HttpTask body is sent as typed: a quote in a value can end a JSON string and add fields. When a body carries user text, build it in the JavaScript Module with JSON.stringify.
• Queries. File Query passes every {variable} in your SQL as a bound parameter, never as SQL text: write WHERE email = {email}, not a query assembled from pieces.
• Emails and documents. HTML email and document templates encode every value, so user text cannot add markup.
• Decisions. Never let raw user text pick a branch that matters (a refund, an approval, a role). Normalise it and compare it with fixed keywords (StringNormalizationTask then a SwitchTask), use buttons or form choices, or require an operator's approval. Treat an AI step's answer about user text as a suggestion: check it against a fixed list before acting on it.

File fields

Every property that reads or writes a file (a File, Attachments, Save as, a File Query table) works the same way on every Module. A switch above the field says where the file is:

Switch	Value	What it means
Session	ref-session:{report}	A file of the running Session: type { and pick a variable that holds a file ({form.fields.file}, {email.attachments.0}, {result} from a previous Task).
Storage	ref-storage:customers.xlsx	A saved file of this Environment, the one you see on the Storage page.
Workspace	ref-workspace:prices.xlsx	A saved file shared by every Environment of the Workspace (older spelling ref-storage-shared:, still read).
Template	ref-template:welcome.html, ref-template:invoice.docx	An email or document template of Templates, read as a file (only on fields that read templates). Flows never change a template.

In a Save as field the part after the prefix is the name of the new file: ref-session:report.xlsx keeps it in the Session, ref-storage:report.xlsx saves it on the Storage page. The Task's output variable always receives the file, ready for the next file field.

Saved-file names follow the Storage page's rule: letters (any language), digits, ., - and _; any other character becomes _, exactly as when you upload the file on the page, so ref-storage:Copia di clienti (1).xlsx finds Copia_di_clienti__1_.xlsx. Files have no folders: a name with / (ref-workspace:reports/q3.xlsx) is refused, and a Process that uses one can't be deployed.

Browse next to the name lists the saved files of the chosen place: on the Storage switch, the files of this process's Environments; in the process editor also the files other Tasks of the flow save there ("saved by Create report in this flow"), before any run has made them.

Files never travel through the Session as content: a variable only holds the file's name, type, size and a reference. Fields that list several files (Attachments) accept several locations separated by commas: ref-session:{report}, ref-storage:terms.pdf. A value written without a prefix ({report}, as in Processes built before the switch existed) is read as a Session file.

Common configuration patterns

Setting an output variable

Many Tasks write their result to a Session variable. You specify the variable in an Output or Store result in property, written in braces ({userName}). Downstream Tasks can then read from that variable with the same {userName} reference.

Reading an input variable

Tasks that process existing data require an Input or InputVar property pointing to a Session variable set earlier in the workflow.

Configuring gateway outputs

The SwitchTask (mapped to an Exclusive Gateway) requires you to define a list of Outputs, each with a name and comparison conditions. The output names must match the labels on the outgoing Sequence Flows from the gateway.

Best practices

1. Use consistent variable names adopt a naming convention (e.g., camelCase) for all Session variables to avoid mismatches.
2. Configure Tasks before deploying a Task with no data causes error 3001 TaskNoData at runtime.
3. Test incrementally after configuring a new Task, deploy and test with the Chat panel before adding more complexity.

Related pages

• BPMN Editor editor overview and toolbar controls.
• Elements reference for all available BPMN elements.
• Standard Module properties for core Tasks like Input, Output, and Switch.