process-mining

latest

false

Process Mining

DELIVERY:

Automation Cloud Automation Cloud Public Sector Automation Suite Standalone

Last updated Feb 28, 2025

How does process tracking work

Think of process tracking as a system that enables you to follow the progression of a claim as it moves through various stages across multiple systems in a claims management process.

In this context, the Process Tracking Service refers to each individual process instance that processes a single claim as a trace.

The primary goal of the Process Tracking Service is to provide a comprehensive, end-to-end view of the process execution from a business perspective. By default, it generates some implicit tracking data. Additionally, it allows RPA developers to implement explicit tracking throughout the process, thereby adding more business context.

Let's consider a Claim Processing Example, which involves four different automations.

Automation	Description
Claim Intake	A Dispatcher built using ReFramework. It runs every morning, and each new claim received is added to a Queue as a Queue Item. The task linked to this step, has a reference to the JobID that was executed. Note: Claim Intake is linked with Evaluate Claims through a Queue as Dispatcher Performer.
Evaluate Claims	A performer built using the ReFramework. It runs every midday and processes every queue transaction. It performs multiple checks, and if it passes all evaluations, a job is started to process the claim. The task linked to this step, has a reference to the QueueItem that was executed.
Process Claim	Long running workflows that raise an Approval Action Center task (Approve High Claim) if a high claim is processed. Once the approval step is completed, the claim is added to SAP. The task linked to Approve High Claim task, has a reference to the TaskID that was executed. Note: Process Claim is an automation started by Evaluate Claims using Start job.
Archive Closed Claim	Every end of week, the automation runs and retrieve every claim from SAP with status Closed and archives all the documents. Note: Archived Closed Claim is linked with Process Claim through the Claim Object entity added in SAP.

Process summary

The process name is "Claim Management".
The trace ID tracks the end-to-end execution of each Claim ID.
The implicit tasks in the trace are:
- Claim Intake;
- Evaluate Claims;
- Process Claim;
- Approve High Claim.
For every task, the RPA developer can decide if they want to add business objects to the task, the initial claim document reference, or the claim information from SAP.

Implicit Process Tracking

Using implicit process tracking, each automation execution of an automation generates a trace and each automation is considered a task. This means that when an automation executes, a trace and a task are generated.

If two automation workflows have a linkage (via a QueueItem or via a Start Job and Get Reference activity), the trace ID is passed from one automation workflow to another to capture the causality.

Therefore, if the above Claim Processing automation is updated with the latest Robot and System package and runs for a while, the Process Optimization app generates the following process graph:

The Archived Closed Claim automation does not appear in the process graph because it is not linked to the Process Claim through a UiPath component. Instead, it is connected via an external system. To establish this linkage, it is needed to implement Explicit Process Tracking.

Traces, processes, and tasks generated by the Robot

UiPath Robot, in conjunction with the activities configured in an automation workflow, is responsible for managing the default business process tracking.

If an automation is not triggered from another automation, the following steps are performed:

Start automation
- Starts a new trace, with the same process name as the one published in Orchestrator.
- Starts a new task, with the process name that is published in Orchestrator as the task name.
Stop automation
- Ends the task.

Note:

The automation process execution is always in the context of a trace and a task.
Implicitly, every automation process is considered a task, and every automation process execution is considered a trace, which has a task.

Trace ID propagation

Trace ID propagation refers to the behavior of when the trace ID of an automation, for example, A1, propagates automatically to an automation A2. All tasks in automation A2 belong to the trace ID of the automation A1.

Important:

The activities listed on this page support Process Tracking Service only when the automation containing them has the Process tracking option enabled.

The following table summarizes the activities that generate trace ID propagation:

Activities	Trace ID propagation
Job-related activities Start Job Start Job and Get Reference	Occurs when automation A1 triggers automation A2, the trace ID generated by automation A1 propagates automatically to automation A2. All tasks in automation A2 belong to the trace ID of the automation A1.
Queue-related activities Add Queue Item Add Transaction Item Add Queue Item and Get Reference	Occurs when automation A1 creates a queue item QI-1 using the mentioned activities. The trace ID generated by automation A1 propagates automatically to the automation that processes the queue item QI-1.
Action Center-related activities Wait for Form Task and Resume Wait for External Task and Resume Wait for App Task and Resume	Occurs when automation A1 creates a human-in-the-loop action, manageable through Action Center. The trace ID generated by automation A1 propagates automatically to the Action Center task.
Intelligent OCR-related activities Wait for Document Classification Action and Resume Wait for Document Validation Action and Resume	Occurs when automation A1 creates a document validation or classification action, manageable through an Action Center task. The trace ID generated by automation A1 propagates automatically to the Action Center task.

Task ID generation

Task generation refers to the behavior of when an automation, for example, A1, is suspended and waits for an external event to complete before resuming, such as a different automation to be fully executed, processing queue items, or waiting for an external task to complete.

Important:

The activities listed on this page support Process Tracking Service only when the automation containing them has the Process tracking option enabled.

The following table summarizes the activities that generate new task IDs:

Activities	Task ID generation	Task name syntax	Task start and end timestamps
Queue-related activities Get Transaction Item / Add Transaction Item + Set Transaction Status Get Transaction Item / Add Transaction Item + Postpone Transaction Item Wait for Queue Item and Resume	Occurs when automation A1 starts and processes a queue transaction. Automation A1 maps queue item statuses to task statuses: Successful queue item - Successful task Failed queue item - Failed task Postponed queue item - Cancelled task	<ProcessName-QueueName>—combines the process name that processed the queue item and the queue name where the item is located.	Task start timestam—when automation A1 starts processing the queue item. Task end timestamp—when automation A1 sets the queue item status or postpones the queue item.
Job-related activities Wait for Job and Resume	Occurs when automation A1 is suspended and waits for automation A2 to be fully executed before resuming.	<ProcessName>—refers to the name of the process for automation A2, as published in Orchestrator.	Task start timestam—when automation A1 suspends. Task end timestamp—when automation A1 resumes.
Action Center-related activities Wait for Form Task and Resume Wait for External Task and Resume Wait for App Task and Resume	Occurs when automation A1 waits for a human-in-the-loop action to complete.	<NameOfTheWaitActivity>—refers to the name of the "Wait for" activity, as set at design time in UiPath Studio.	Task start timestam—when automation A1 suspends. Task end timestamp—when automation A1 resumes.
Productivity activities Google Workspace - Persistence Activities (that start with `Wait for`) Microsoft 365 - Persistence Activities (that start with `Wait for`)	Occurs when automation A1 is suspended and waits for automation A2 to be fully executed before resuming.	<ActivityNameInStudio>—refers to the name of the persistence activity set in Studio at design time.	Task start timestamp—when automation A1 suspends. Task end timestamp—when automation A1 resumes.
Integration Service - Wait for an Event and Resume activities	Occurs when automation A1 is suspended and waits for a certain event in a third-party application to be fully executed before resuming.	<ActivityNameInStudio>—refers to the name of the Integration Service persistence activity set in Studio at design time.	Task start timestamp—when automation A1 suspends. Task end timestamp—when automation A1 resumes.
Intelligent OCR-related activities Wait for Document Classification Action and Resume Wait for Document Validation Action and Resume	Occurs when automation A1 waits for a human-in-the-loop action to finish.	<NameOfTheWaitActivity> – refers to the name of the "Wait for" activity, as set at design time in UiPath Studio.	Task start timestamp – when automation A1 suspends. Task end timestamp – when automation A1 resumes.

Track Object

Object tracking

Object tracking: When an automation, for example, A1, creates an object O1 via Integration Service "Create" activities, it tracks its progress through automation A2 using the O1 Object type and Object ID properties. Exceptions are the "Read" or "List" activities.

Each Integration Service "Create" activity adds the tracking for their object as follows:

Object type: <IntegrationServiceObject>, for example, "Account"
Object ID: <System Object ID>, for example, "0010700000gMXRqAAO"
Object interaction: <Based on the activity used>, for example, "Create", "Update", or "Delete"
Object properties:
```
{
  XUiPathConnectorKey: "<XUiPathConnectorKey>",  // for example, XUiPathConnectorKey: "uipath-salesforce-sfdc"
  XUiPathConnectorName: "<XUiPathConnectorName>",  // for example, XUiPathConnectorName: "Salesforce"
  XUiPathObjectDisplayName: "<XUiPathObjectDisplayName>",  // for example, XUiPathObjectDisplayName: "Account"
  XUiPathObjectName: "<XUiPathObjectName>"  // for example, XUiPathObjectName: "curated_account"
}{
  XUiPathConnectorKey: "<XUiPathConnectorKey>",  // for example, XUiPathConnectorKey: "uipath-salesforce-sfdc"
  XUiPathConnectorName: "<XUiPathConnectorName>",  // for example, XUiPathConnectorName: "Salesforce"
  XUiPathObjectDisplayName: "<XUiPathObjectDisplayName>",  // for example, XUiPathObjectDisplayName: "Account"
  XUiPathObjectName: "<XUiPathObjectName>"  // for example, XUiPathObjectName: "curated_account"
}
```

Explicit Process Tracking

Explicit Process Tracking enables RPA developers to enhance the implicit Process graph by adding additional tracking data, making it more aligned with a BPMN view.

Typically, each automation workflow consists of multiple tasks and processes various objects. The Process Owner must have end-to-end visibility of these flow paths, tasks, and objects. This clarity can significantly improve workflow management and efficiency.

Using explicit process tracking activities, the RPA Developer can track additional Task and Objects or manage Traces and Processes and track them spanning external systems.

The following illustration displays the Claim Process with explicit tracking added.

Enable Process Tracking on a Sequence

RPA developers usually group the functional and logical steps in separate Workflows or Sequences. These logical steps can be valuable Tasks that a Process Owner or a Center of Excellence (COE) Lead would like to track.

In a situation where automation is already in place and explicit process tracking is needed, it is crucial to ensure a smooth experience for RPA developers without disrupting the workflow logic. To achieve this, the Process tracking property is selected to enable any Sequence to generate a Task.

Process Tracking Scope

The Process Tracking Scope can be added to the canvas like any other activity used to track specific business sequences in UiPath Process Mining. Check out Process Tracking Scope activity in the Workflow Activities guidefor more information.

Task generation

Process Tracking Scope creates a Task with the start timestamp when the scope begins and with the end timestamp when the scope ends.

Nested Task generation

If a Process Tracking Scope is added within another Process Tracking Scope, the inner Scope will generate a Task as a child Task. The parent-child relationships is maintained in the Process Tracking structure and can be visible through Hierarchical Process Mining in the Process Graph.

Implicit Task status

The default status of the task will be set to "Successful."

When an uncaught exception occurs inside the activity, the task is closed with the status "Failed", and the exception is made available in the Process Optimization app.

Explicit Task status

The Set Task Status activity allows you to explicitly control the ending of a specific task within a Process Tracking Scope. It enables accurate representation of individual steps completion in analytics.

The Set Task Status activity is useful when you need to assign a status that differs from the implicit "Successful" or error-triggered "Failed" states. This might depend on your workflow-logic.

For instance, in a document processing workflow, a task verifies that all documents exist. If a document is missing, use Set Task Status to mark the status as "Cancelled". Follow-up actions could include sending a revision request to the expeditor.

Also check out Set Task Status activity in the Workflow Activities guide.

Trace ID propagation

Process Tracking offers different options for propagating the Trace ID.

Trace ID propagation in the current trace

The current Trace ID is passed to the newly created Task, tracking it in the same Trace.

Note:

The context of the Trace is changed when using the following activities:

Or:

Wait for Queue Item and Resume

Or:

Wait for Job and Resume

When these activities are used, due to implicit tracking, any explicit Tasks that are configured in the execution of the invoked Job or in the processing of the QueueItem would be tracked as the initial Trace that created the Job or QueueItem.

Trace ID propagation in a new trace

The activity generates a new Trace ID and tracks the newly created Task inside the new Trace. The RPA developer needs to specify the Process name to which the new Trace should be assigned.

At the end of the scope, the Task will be closed, and the Trace context will be changed back to the previous one.

Trace ID propagation in an existing trace

Select this option if you need to add the Task to an existing Trace. Typically, this different Trace is part of a separate automation process that is not linked through Queues or Jobs.

To find an existing trace, you must identify it by the combination of the Object details and the Process name associated with that Object. For example, The Invoice Processing trace where Invoice UIP-100 has been Created.

Explicit Trace Status - End Trace

The Set Trace Status activity allows you to manually control the ending of a trace within a Process Tracking Scope. It enables accurate representation of process completion in analytics. If you do not explictily end the trace, it remains active indefinitely.

It is recommended to use this activity to mark the completion or failure of a larger process.

Also check out Set Trace Status activity in the System activities guide.

Track Object

The Track Object activity enables you to configure and monitor an Object for a specific Task. The Object can provide additional context data in the Process Optimization app. The Object can also be used to connect two different automations by tracking a Task within an existing Trace. In this case, the Object associated with that Trace is located.

Note:

Process Tracking is not a system of records.

Check out Track Object activity in the Worflow Activities guide for more information.

Common Explicit Tracking patterns across automations

Each Queue Transaction, a different Trace

In certain scenarios, each Queue Item represents a different Process instance, and it is necessary to track each instance as a separate Process Tracking Trace. To accomplish this, the RPA developer must identify when a new Trace begins and properly surround that sequence with a Process Tracking Scope to configure the Task to be tracked in a New Trace.

It is important to note that at the end of the Process Tracking Scope, the Task concludes, and the context shifts back to the higher-level task, which may be associated with a different Trace.

A recommended solution is to surround the Add Queue Item within the Process Tracking Scope and track a Task in a New Trace. This way, each Queue Item will be assigned a new Trace.

If your process involves multiple Dispatcher-Performer automation workflows and several Queues, it is advisable to implement this workflow update only on the first Dispatcher. Subsequent Queue Items from the other Queues will already be associated with different Traces. After the Queue Item is added, an additional task, Inform Customer, should also be created.

Propagate a Trace through external systems

There are scenarios where the process requires an automation to pass the Trace through external systems before returning to a second automation. The following illustration shows the Claim Processing example, where the Process Claim automation adds the Claim in SAP. After a certain period of time when the Claim reaches a specific Status a second automation takes the claim back and archive it together with all the documents.

The only connection between the two is the Object added to SAP. For the Archive Claim to associate a Task with the same Trace as the one used in Process Claim, the first automation must track the SAP Claim Object. Subsequently, the second automation must implement a Process Tracking Scope to add a Task to the existing Trace, identifying it based on the object details recorded during the previous automation. Additionally, ensure that both Automations are part of the same Process by using the same Process name in the second automation as that in which the first automation is included.Ensure that both Automations are part of the same Process by using the same Process name

Note:

The object identification details recorded in the first process must match the details entered in the external system to avoid duplicating fields.

If the object details are the same, you can use Process Mining to incorporate additional external systems into the same Process Optimization app.

On this page