#Work with process data
A running process carries its data in a context, where the start data and the result of every finished step are filed under the id of the element that produced them.
#How data builds up while a process runs
flowchart LR S["Start event<br/>StartEvent_1<br/>(the start data)"] --> T1["Service task<br/>Activity_fetch<br/>(the system's response)"] T1 --> T2["User task<br/>Activity_review<br/>(what the person entered)"] T2 --> T3["Next step<br/>reads StartEvent_1.orderId,<br/>Activity_fetch.creditLimit,<br/>Activity_review.approved"]
Each step adds its result to the context, under its own element id. A later step reads
it by that id and the field name. The element's display name plays no part in this:
renaming Fetch customer changes nothing, while changing its id Activity_fetch
breaks the references to it.
| Where the data comes from | What it holds | Read it as |
|---|---|---|
| The start event | The data the process was started with | StartEvent_1.orderId |
| A service task | The system's response. A response that is not JSON arrives as body |
Activity_fetch.creditLimit |
| A user task | Every field of its form, by field key | Activity_review.approved |
| A multi-instance step | One result per iteration, as a list | Activity_fetch |
| A sub-process | The results of the steps inside it, by their ids | SubProcess_1.Activity_check.status |
| The person who started it | Their id, email, name and company details | __INITIATOR.email |
Inside a multi-instance step, __loop.item is the current element of the list, and
__loop.index its position.
A step only sees what happened before it on its path. What a later step will produce is not available yet, and the Designer does not offer it.
#Define what a process receives
The data a process starts with is described by its input schema, on a plain start event:
- Select the start event and open the Input schema group in the properties panel.
- Click Add input schema. The editor opens with a list of fields; add one with + Field.
- Give each field a name and a type — String, Number, Integer, Boolean, Object, Array or File — and mark it required or optional.
- Code switches to the JSON schema itself, for settings the field list does not show, such as a pattern or a list of allowed values.
- Apply puts the schema into the diagram; Save on the process stores it.
With no input schema the process starts without data.
The input schema is used in several places:
- Its fields are the start event's data — they are what later steps can read under the start event's id.
- A person starting the process by hand fills them in. Switch on Manual start to offer that, and optionally pick a Form there; its answers are then mapped onto the schema fields. See Forms.
- Another process calling this one fills them in, in the calling step's Input parameters — once this process has a production deployment.
- An agent using this process as a tool fills in these fields, except the ones that are already preset.
From successor on a field takes a field that a later service task, call activity or sub-process expects, adds it to the schema, and fills that later field with a reference to it.
⚠️ The data is checked against the schema only when a person starts the process through a start form. A start through the schema fields, by another process or through the API is not checked, and formats such as an email address are never checked.
⚠️ Saving the schema from the field list drops settings the list does not show, such as a maximum length. Keep those in the Code view and apply from there.
#Use data in a later step
Every value field in the properties panel has two buttons:
- + Pick variable opens a list of everything available at this point: one group per earlier step, named after it, with its fields and their types. Insert puts the reference into the field. Fields whose type cannot fit are greyed out.
- ƒ turns the field into an expression, for when a value has to be computed. See Expressions.
A step whose own configuration is invalid disappears from the list until you fix it.
#What a process returns
- A service task returns what the system answered. Its Response body group shows the shape of that answer, read-only; it comes from the action. See Systems and adapters.
- A user task returns its form's fields.
- A call to an agent returns the fields of the agent task's response — or, without them, the agent's text.
❌ A plain process has no output of its own. An end event cannot be given a result, and there is no output mapping. A process that calls another process gets all of that process's step results at runtime, but the Designer offers none of them to pick, so they cannot be referenced.
⚠️ Some labels here are German whatever the language of the screen: the Array Variablen tab of the variable list, and Collection Quelle and Abschlussbedingung in the multi-instance settings.