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.
A process run is a single execution, triggered by an event after which the steps in the process are executed in order, triggered by work items outputted by the previous step run.
For example: (Input →) Step 1 → Step 2 → Step 3 (→ Output)
When a process run is triggered:
- Without data - an empty work item is created at 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:
- All work items that were used to initialize the run, or were created in it, can be found under the parent process run
- E.g. if Step 1 is run multiple times due to parallel executions, they all can be found under the parent process run
Process run preserves the context of retried work items:
- For example: 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
The available trigger events are:
You may need to stop an ongoing process run. This could be because you identified a flaw in your logic, or because you noticed that one of the services you talk to as part of your automation is not responding anymore. No point in wasting those run minutes!
Stopping a process run is really easy and gives you a lot of flexibility:
- You can control whether you want the step runs to complete their work
- You can control in which state you want the pending (unprocessed) work items
Once you have clicked the
"Stop run", the process run will enter the
Stopping state until the requirements you specified have been met.
The final state of the process run will be either
Unresolved depending on the choice you made and the implementation of your process.
Your step runs will finish their work, as if nothing happened, but Control Room will not start any new step runs after you have asked to stop the process run.
Control Room will send a message to the robots telling them to stop everything that they are doing right away: the work items that were being processed will be automatically failed.
failedstate if you want to be able to re-process these work items after you have fixed the issue you identified (and the reason why you stopped the process run in the first place!)
donestate if you don't need to re-process these work items, for example when running test data during robot development.
The following attributes of the Process Runs can be found in the Process Runs tables. Some of the columns are not enabled by default and can be toggled from the table settings.
Each process run is assigned a unique run number identifier when it is created, starting from 1 and counting up.
The current state of the process run.
Which user or event triggered the run start, e.g., manually, via API, or via Scheduler.
The time when the process run was created.
Process run lead time measures the time between the run start and run complete, indicating the time taken for all the Work Items in the run scope to be successfully processed or marked as Done. It is not related to billed run minutes used by the run and is only an informational metric.
The total amount of Work Items in the run scope aggregated over steps.
Amount of Output Work Items generated in the run.
Amount of Work Items in the run scope that are in "Failed" state, meaning that there is an exception that needs to be handled.
The run is processing pending work items.
The run needs interaction from the user to resolve issues with failed work items.
A request to stop the process run has been initiated by a user or via API.
Every work item in the process run has been successfully processed by the robot or marked as done by the user.