Process Definition

A workflow process consists of process elements start/end events, and user/service tasks, gateways linked with connectors flows, thus forming an ordered set of events and handling actions.

To configure a process definition:

1. Navigate to the Properties > Process tab.
2. Define the following fields:
   • Id - For example: recommendForDelete
     Note: The process ID should be unique among multiple processes running in the same Reltio environment.
   • Name - For example: recommendForDelete
   • Start Event
   • End Event

Process Configuration

On the process level, you can configure the following properties:

Text Annotations and Associations

To configure a process:

1. Navigate to the Properties > Data Objects tab.
2. Click the New button.
3. In the Data property configuration dialog, define the following fields:
   • Id - Example: possibleAssignees
   • Name - Example: possibleAssignees
   • Type - Example: string
   • Value - Example: ROLE_UI_ALL

Task Definition

Task is a process element used in workflow to specify a human activity

User Task Configuration: Listener or a system action Service Task Configuration.

To configure a task definition:

1. Add a new task element to the diagram work area.
2. Specify the one of the following task types:
   • User Task Configuration: Listener
   • Service Task Configuration
3. Navigate to the Properties > General tab.
4. Define the following fields:
   • Id - For example: deleteReview
   • Name - For example: deleteReview
5. Enable/disable the Asynchronous OFF by default and Exclusive ON by default options.

User Task Configuration: Listener

To configure a listener for a user task:

1. Navigate to the Properties > Listeners tab.
2. Click New.
3. In the Listener configuration dialog, define the following fields:
   • Event - For example: create
   • Type - For example: Java class
   • Fields:
     • Field name
     • String value
     • Expression

Listener on Create

Used to:

• Determine due date for the process instance using the dueDateDelta property value
• Assign the task using the round-robin algorithm among possible assignees using the possibleAssignees property value

Properties:

• Event: create
• Type: Java class
• Implementation: com.reltio.workflow.activiti.service.TaskStartEventListener

Stateless listeners

All custom workflow listeners must be stateless. This includes both WorkflowTaskListener and WorkflowAction implementations.

A stateless listener does not store any execution-specific data in class-level variables. Instead, all data needed during execution must be passed as method arguments or retrieved from the Task or Execution object in the method scope.

Stateless design is required because Reltio may reuse the same listener instance across different tasks. Storing contextual data in class fields can lead to incorrect behavior when multiple tasks are executed in parallel or sequentially on the same object instance.

Here's an example of an incorrect, stateful implementation:

public class StatefulTaskListener implements WorkflowTaskListener {
  private String accessToken;

  @Override
  public void notify(Task task) {
    accessToken = task.getAccessToken();
    callSomeAPI();
  }

  private void callSomeAPI() {
    // Uses accessToken stored in class field
  }
}
  

The correct, stateless version of the same logic:

public class StatelessTaskListener implements WorkflowTaskListener {

  @Override
  public void notify(Task task) {
    String accessToken = task.getAccessToken();
    callSomeAPI(accessToken);
  }

  private void callSomeAPI(String accessToken) {
    // Uses accessToken passed as method argument
  }
}
  

Always design listeners so they behave independently for each execution context. This avoids unintended side effects or data leakage across tasks.

Secrets in custom code

In some cases, custom workflow code may need to authenticate against third-party systems, such as internal APIs or cloud services. These external calls often require credentials or access tokens.

To avoid hard coding sensitive information, you should store credentials as encrypted process properties in the workflow definition. These values can then be decrypted at runtime using a secure key embedded in the custom code.

This approach provides the following benefits:

• Credentials can be rotated without changing the custom code.
• Different credentials can be configured for different tenants.
• Process types (e.g., DCR vs PMR) can use different secrets.

The following example shows how to retrieve encrypted credentials and decrypt them in a listener:

String username = (String) executionService.getVariable(execution.getId(), "notificationUser");
String password = (String) executionService.getVariable(execution.getId(), "notificationPassword");

username = decrypt(username);
password = decrypt(password);

// Proceed with using credentials securely
  

Use an established encryption algorithm such as AES-GCM to encrypt and decrypt values. Store the encryption key securely in your code and never expose it via logs or task variables.

User Task Configuration: Form

Decision

Validator

To configure a Validator form property for a user task:

1. Navigate to the Properties > Form tab.
2. Click New.
3. In the Form property configuration dialog, define the following fields:
   • Id - For example: validator
   • Name - For example: validator
   • Type - For example: string
   • Default - For example: com.reltio.workflow.interfaces.validator.SingleEntityTaskValidator, com.reltio.workflow.interfaces.validator.PotentialMatchTaskValidator
   • Readable - For example: True

Service Task Configuration

To configure a service task:

1. Navigate to the Properties > Main > config tab.
2. Define the following fields:
   • Class name - For example: com.reltio.workflow.activiti.service.Delete, com.reltio.workflow.activiti.service.NotAMatch, com.reltio.workflow.activiti.service.Merge

Gateway definition

Gateways are used to fork and join flows inside a process. For example, if there are two possible decisions Delete and Cancel, two flows will link one exclusive gateway to two service tasks (or to a service task and an end event).

Flows are used to link process elements. For example, a user task and a service task, a gateway and a service task, a gateway and an end event, and so on.

To configure a flow:

1. Navigate to the Properties > General tab.
2. Define the following fields:
   • Id - For example: cancel
   • Name - For example: cancel

Flow configuration

To configure a flow:

1. Navigate to the Properties > Main config tab.
2. Define the following field: Condition - For example: ${decision=='cancel'}

XML View

As an alternative to the Diagram View with visualized process elements, Activiti Designer provides XML View where process elements and their properties can be viewed/edited as regular XML formatted content.

To open a process diagram in XML View:

1. In Activiti Explorer, right-click the process diagram.
2. In the popup menu, select Open With > XML Editor.

Exporting Workflow diagram

To export a workflow diagram to a file:

1. In XML View, navigate to File > Save As....
2. Specify destination and file name according to the following mask: *.bpmn20.dita.

Required Permissions

Workflow Adapter has role-based permissions for operations, and you can assign any Reltio role to any API endpoint of Workflow Adapter. For details on the API operations and required permissions, refer Reltio Permissions Framework. For details on the Workflow operations, refer Workflow API.

Notes:

• List of Reltio roles are to be configured against each of these permissions.
• Task execution (making a decision) can be done only by the assignee of the task.