Process runs in a process

Process run maps the data handled in single process execution, even when the execution contains multiple work items or is processed with multiple parallel robots.

Process run ends up in an Unresolved state if there are failures in processing the work items and is considered Complete when all the failed work items are retried successfully or resolved by the user. A common pattern is to set automatic notifications to track processing failures. The user can then look up and solve the issues in the unresolved process runs from the Work Item Explorer.

Process run is a single execution of a process triggered by an event
- (Input →) Step 1 → Step 2 → Step 3 (→ Output)
Available triggers events currently are
- Manual
- Scheduler
- E-mail
- API
When a process run is triggered
- Without data, an empty work item is created to Step 1, and a Step run is started
- With data (1-n work item payloads), the items are passed to Step 1, and a Step run is started
Process run contains all step runs and work items in the context of that run
- E.g. if Step 1 is run multiple times due to parallel executions, they all can be found under the parent process run
- All work items that were used to initialize the run, or were created in it, can be found under the parent process run
- Process run preserves the context of retried work items
  - E.g if a work item fails in a step run in step 2, retrying it with a different step run later does not lose the context that it was in the parent process run
Users can stop a process run by
- Terminating, which causes all step runs to terminate immediately and all work items in them to fail accordingly. All the unprocessed items will fail with an exception message.
- Stopping, which causes all step runs to process the item they are processing currently, and then stop executing. All the unprocessed items will fail with an exception message.

Process runs in a process

Process run states

Processing

Unresolved

Terminating

Completed