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 flow and triggers
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
Process run trigger events
The available trigger events are:
- Manual
- Scheduler
- API
Stopping a process run
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 Completed or Unresolved depending on the choice you made and the implementation of your process.
What happens when I let the step runs complete?
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.
What happens when I terminate the ongoing step runs?
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.
Which state should I choose for the pending work items?
-
Choose the
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!) -
Choose the
donestate if you don't need to re-process these work items, for example when running test data during robot development.
Process run attributes
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.
Run number
Each process run is assigned a unique run number identifier when it is created, starting from 1 and counting up.
Status
The current state of the process run.
Run by
Which user or event triggered the run start, e.g., manually, via API, or via Scheduler.
Run time
The time when the process run was created.
Lead time
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.
Total WI
The total amount of Work Items in the run scope aggregated over steps.
Outputs
Amount of Output Work Items generated in the run.
Failed WI
Amount of Work Items in the run scope that are in "Failed" state, meaning that there is an exception that needs to be handled.
Process run states
Processing
The run is processing pending work items.
Unresolved
The run needs interaction from the user to resolve issues with failed work items.
Stopping
A request to stop the process run has been initiated by a user or via API.
Completed
Every work item in the process run has been successfully processed by the robot or marked as done by the user.