Reltio Connect

Hi,

We have a use case to build around DCR as follows:

1. The Data Steward (DS) suggests updates to a profile via a DCR (Data Change Request).
2. There are department-specific reviewers.
3. If the updated attributes fall under Dept 1, only Dept 1 reviewers should review and either approve or reject them.
4. If the updates span multiple departments, starting with Dept 1, the DCR should pass on to Dept 2, and then Dept 3, with each department reviewing only its respective set of attributes.
5. After all departments have completed their reviews, only the attributes approved by the respective departments will be updated in the record.
6. For example, if Dept 1 and Dept 3 approve their attributes but Dept 2 rejects its attributes, only Dept 1 and Dept 3's updates will be applied, while Dept 2's attributes will remain unchanged.

Please suggest an approach for implementing this use case.

Thank you!

Hello Gayatri,

One approach would require customizing the DCR workflow logic and flow. The process should first read the initial DCR request, determine which attributes are being suggested and the teams that are responsible. When the determination is made, new child DCRs should be created (by the service task) for each team along with their respective attributes for review. The initial parent DCR can then be deleted or used for a primary team.

Here is an example of a BPMN modeler that has a DataChangeRequestDeciderStep to read the initial DCR, identify the changes, and determine if child DCRs need to be created. There was also an Auto Reject Service implemented for conditions where the workflow should be rejected automatically.

The DataChangeRequestDecider class is part of a workflow automation system that handles data change requests for entities within a specific environment.

1. Change Request Handling:

   • It retrieves the change request URI and invokes the Reltio API to get details about the change request.
   • The method checks the types of changes (e.g., creating a new entity).

2. Entity Type Decision:

   • The code determines if the change involves creating a new entity (specifically checking for healthcare organizations or products).
   • It examines attributes such as customer type and country to set variables that dictate the workflow path and approvers.

3. Flow Control:

   • Depending on conditions (like entity type and attributes), it sets a variable FLOW_DECIDER to control the next steps (e.g., "AUTO_REJECT", "NORMAL_FLOW").
   • It also assigns a reviewer role based on the entity's attributes.

4. Logging: The class includes logging for debugging and tracing execution flow.

In summary, this class implements logic to assess data change requests and determine how they should be processed based on specific criteria related to the entities involved.

------------------------------
Bryant Barrenechea
Solution Architect | Professional Services
------------------------------