#Where expressions are used

Expressions appear on gateways, in adapter requests, emails, user tasks, multi-instance settings, sub-process inputs, message events and form conditions — each one reads its own data, is worked out at its own moment, and fails in its own way.

#Where they are worked out

flowchart LR
  subgraph Chester["In Chester, in a sandbox"]
    G["Gateway conditions"]
    R["Requests, emails,<br/>user tasks, inputs"]
    M["Message filters"]
  end
  subgraph Browser["In the browser of the person"]
    C["Display control,<br/>Input control"]
  end
  D["Process data"] --> G
  D --> R
  Q["The incoming request only"] --> M
  F["The form's values"] --> C

Almost every expression is worked out by Chester, in a sandbox that sees only the data listed below. Form conditions are the exception: they run in the browser of the person filling in the form.

#In the process

Where	Result	Reads	Worked out	If it fails
Condition on a path out of an exclusive or inclusive gateway	true / false	process data	when the process reaches the gateway	the step fails
Path, Query, Headers, Request body of a service task or message throw	object; the body also a list or value	process data	when the call is made	the step fails, without a retry
Recipients & subject, Attachments of a send task	text or list	process data	when the email is sent	the step fails
ƒ calculations in the Email content	text or HTML	process data	when the email is sent	⚠️ left empty, the email is sent
User (expression) of a user task	a user id	process data	when the task is created	the step fails
Display title of a user task	text	process data	when the task is created	⚠️ the element's name is shown
Form data input, Option data of a user task	per field	process data	when the task is created	the step fails — see Fill a form
Collection Quelle of a multi-instance step	list	process data	once, when the step starts	the step fails
Required completions of a multi-instance step	number	process data	each time a run finishes	the step fails
Input parameters of a sub-process or call activity	per field	process data	when the step starts	the step fails
Signal payload of a signal throw	object	process data	when the event is reached	the step fails
Correlation ID of a message catch	text	process data — not the message	when the process starts waiting	⚠️ the text itself is used as the ID
Mapping of a start form onto the input schema	per field	only `formData`	when the person starts the process	the process does not start — see Fill a form

#On incoming requests

Where	Result	Reads	Worked out	If it fails
Filter of a message start or message catch	true / false	only `payload`, `headers`, `query`	for every request	the request is refused; nothing starts or continues
Registration request body and the other request bodies of an inbound action	object or list	a catch: process data; a start event: nothing	when the webhook is registered — for a start event, at deploy	the registration fails
Delta query parameters and body	object	only the cursor, `_inbound.cursor`	for every notification	the notification is not processed
Delta Query Transform	list	only `deltaResponse`	for every notification	the notification is not processed
Duplicate-detection key of an inbound action	text	only `payload`, `headers`, `query`	for every request	⚠️ the request is processed without duplicate detection

⚠️ Start Condition (optional) in the Delta query group is saved but never worked out.

#In the form, in the browser

Where	Result	Reads	Worked out	If it fails
Display control of a user task	true / false	the form's values, `item` and `index` per row, and what the form was filled with	live, on every change	⚠️ the field is hidden
Input control of a user task	true / false	the same	live, on every change	the field stays editable

See Show, hide and lock form fields.

#Not an expression

These take fixed values, not expressions: a timer's duration, a message start event's Correlation Key, the adapter's transformations, response and cursor paths, signal catch and link events.