CMD- Segment Workflow Low-Level Design

Portal:

When the requestor/user logs into the portal, they can edit or unassign segments. When the data approver logs into the portal, they can navigate to the workflow page. Once on the workflow page, they will be able to view the tasks assigned to them.

The approver can then select one or more tasks and click on "Approve" or "Reject." Based on the approver's action, segments will either be promoted or reverted for the customer. If promoted, the segment changes will be published to downstream systems.

Low-Level Design:

Scenario 1: Add New Segments to the Parent Customer

When a new segment is added to a parent customer, it will not trigger the workflow. However, once the segment is added, segment automation should be executed for all child customers associated with the parent, with the exception of customers classified as CUSTOMER TYPE and EFFICIENCY.

Scenario 2: Add New Segments to the Child Customer

Child customers are only permitted to be assigned the following segments:

• CUSTOMER TYPE
• EFFICIENCY

Scenario 3: Update/UnAssign Existing Single Segment of the Parent Customer

• Check Customer Status:
  • Verify if the customer is active.
• If the customer is not active, display a validation message and stop further processing.
  • If the customer is active, proceed to the next step.
• Check Segmentation Workflow:
  • Verify if the customer is already in the segmentation workflow.
  • Check if any of the child customers associated with the parent customer is currently in the segmentation workflow.
    • If yes, throw a validation error with the message: “Customer is already in segmentation workflow or one of the child customers associated with the parent is in workflow.”
    • If no, proceed to the next step.
• Validate Segment:
  • Perform validations for the segment assigned to the customer.
• Trigger Segmentation Workflow:
  • If the segment validation passes, land the customer into the workflow.
• Data Approval:
  • Once the data approver logged into the portal and approves the workflow, proceed with updating the customer's segment.
• Segment Automation for Child Customers:
  • Perform the segment automation for any child customers associated with the parent.
• History Update and Publication:
  • Once the segment automation for child customers is completed, update the history and publish the segment changes to the downstream systems.

Scenario 4: Update/UnAssign Existing Multiple Segments of the Parent Customer

• Current Endpoint Limitation:
  • The segmentation endpoint currently does not support updating or unassigning multiple segments.
  • The behavior of the endpoint needs to be updated to support both single and multiple segment updates/unassignments.
• Implement Validations for Multiple Segments:
  • Implement proper validation logic that can handle both single and multiple segment updates/unassignments.
• Check Customer Status:
  • Verify if the customer is active.
    • If the customer is not active, throw a validation message and stop further processing.
    • If the customer is active, proceed to the next step.
• Check Segmentation Workflow Status:
  • Verify if the customer is already in the segmentation workflow.
  • Check if any child customers associated with the parent customer are in the workflow.
    • If yes, throw a validation error with the message: “Customer is already in segmentation workflow, or one of the child customers associated with the parent is in the workflow.”
    • If no, proceed to the next step.
• Validate Segments:
  • Perform the necessary validation for the segments (whether adding, updating, or unassigning).
• Trigger Segmentation Workflow:
  • If the segment validation passes, add the customer to the segmentation workflow.
• Data Approval Process:
  • Once the data approver logs into the portal and approves the workflow, proceed with updating the customer’s segment.
• Update Customer Segment:
  • Confirm that the customer has exited the regular customer workflow.
  • Incorporate the approved changes into the customer’s segment.
• Segment Automation for Child Customers:
  • After updating the parent customer, perform the segment automation for any child customers associated with the parent.
• History Update and Segment Publication:
  • Once the segment automation for child customers is completed, update the history and publish the segment changes to the downstream systems.

Scenario 6: Update/UnAssign Existing Segments of the Child Customer

• Check Child Customer Status:
  • Verify if the child customer is active.
    • If the customer is not active, throw a validation message and stop further processing.
    • If the customer is active, proceed to the next step.
• Check Segmentation Workflow:
  • Verify if the child customer is already in the segmentation workflow.
  • Check if the parent customer is in the segmentation workflow.
    • If yes, throw a validation error with the message: “Customer is already in segmentation workflow, or the parent customer is in workflow.”
    • If no, proceed to the next step.
• Validate Segment Type:
  • Perform validation to ensure the segment being assigned is of the Customer type or Efficiency type.
    • If the segment type is not valid, throw a validation error and stop further processing.
    • If valid, proceed to the next step.
• Trigger Segmentation Workflow:
  • If all validations pass, allow the child customer to enter the segmentation workflow.
• Data Approval Process:
  • Once the data approver logs into the portal and approves the workflow, proceed with updating the segment for the customer.
• Update Customer Segment:
  • Confirm that the customer has exited the regular customer workflow.
  • Incorporate the approved changes into the customer’s segment.
• History Update and Segment Publication:
  • After segment updates are completed, update the history and publish the segment changes to the downstream systems.

Scenario 7: Regular customer is in the workflow, but the customer segment is not. The user is attempting to update or unassign the segments.

• Add or Edit Segment:
  • Segments can be added or edited for a customer.
  • If it is an update case, the segment will be landed to the workflow.
  • If it is an add case (i.e., adding a new segment), the segment will not be placed in the workflow.
• Add Segment:
  • If the customer does not have any segments:
    • The new segment will be added to the customer without landing in the workflow.
    • Segment automation will then be performed for any associated child customers.
  • Note: If the customer is associated with any child customer, adding the segment vice versa (on the child or parent) is not allowed.
• Update Segment:
  • If a segment update is made, the segment will land into the workflow independently.
  • If the segment workflow gets approved first, and then the regular workflow gets approved, the changes will be applied in the following order:
    • First, the segment changes will be promoted and published.
    • Then, while regular customer changes will be applied , need to take the segment changes and need to update the customer details when they are approved by DataSteward.
  • If the regular workflow gets approved , the changes will be applied in the following order:
    • First regular workflow changes are approved and published.
    • Then, segment changes will be applied when they apporved by Segment Approved.
  • If the segment workflow got rejected , and then the regular workflow gets approved, the changes will be applied in the following order:
    • First , the segment changes will be rollbacked to previous state.
    • Then, while regular customer changes will be applied , no need to take the segment changes.
  • If the segment workflow got rejected , and then the regular workflow gets rejected, the changes will be applied in the following order:
    • First , the segment changes will be rollbacked to previous state.
    • Then, while regular customer changes also be reverted to previous state.

Workflow Service:

• Current Customer Workflow Retrieve API:
  • The existing retrieve API for customer workflows compares the current and previous snapshots of the customer.
• Develop New Segment Workflow Retrieve API:
  • A new retrieve API for the segment workflow is needed.
  • This API should return the differences between the current and previous segments, removing the need for custom logic at the portal level.
• Develop BPMN Model for Segment Workflow:
  • A new BPMN model needs to be developed for segment workflows.
  • The model should include multi-level approvers to handle approval processes.
• Implement Time Boundary for Segment Approval:
  • Implement a time boundary in the workflow:
    • If a segment is not approved within 60 days, the task/workflow should auto-reject.
    • The segment should be reverted to its previous state after auto-rejection.
• Enhance Pending Task Fetching Mechanism:
  • Currently, pending tasks are fetched using the Camunda REST API.
  • A new query mechanism needs to be built to fetch pending records directly from the metadata tables.
• Enhance Workflow API to Support Multiple Record Approval:
  • The current workflow endpoint does not support multi-record approval.
  • The API needs to be enhanced to support multiple records approval for the segment workflow.