Customer Segment Design

Segment Data Management Flow in CMD Portal

The Segment Tab is a dedicated section within the CMD Portal that allows users to manage Segment Data for customers using the Customer Code as input. Users can fetch, create, or update segment data, and the process ensures validation, workflow approval, and seamless integration with downstream systems.

When a user attempts to create or update segment data, the following steps occur:

1. Data Validation: The input data is first sent to the Segment Validation Service, where it undergoes checks for correctness, completeness, and compliance with business rules. If the data fails validation, the user is notified with specific error details, and the process stops.
2. Workflow Approval: If validation is successful, the data is passed to the Workflow Service for approval. During this stage, the data is stored in the Segment Stage Table with attributes such as:
   • Workflow Status (e.g., Pending, Approved, or Rejected)
   • Customer Code
   • Segment Data (Json)
   • Processed Indicator (Y/N)
   • Audit Trail Information If the data is rejected, the workflow status is updated to "Rejected," and no further processing takes place. If the data is approved, the status is updated to "Approved," the Processed Indicator is set to Y, and the Audit Trail is updated accordingly.
3. Data Ingestion: Upon approval, the Ingest Service is triggered to store the segment data into the MDM Customer Segment Table. This ensures that the data is now part of the master system.
4. Parking Lot Scenario: The system is designed to handle scenarios where data processing might fail or remain incomplete. If the Processed Indicator remains N, a Scheduled Job periodically scans and reprocesses these unprocessed records to ensure they are ingested successfully. This ensures no data is left behind.
5. Data Publishing: After ingestion, the Publish Service is triggered. This service fetches the latest snapshot of the complete customer data from Elasticsearch and publishes it to downstream consumers. By leveraging Elasticsearch, the process ensures that consumers always receive the most up-to-date customer information. Notably, this publishing process is decoupled from non-segment data workflows, ensuring there is no impact on the overall Customer Turnaround Time (TAT).

Pending Items:

1. History API needs to be changed for segmentation workflow once approved. If the customer is in workflow, History API will not be triggered.
2. Suppose the Parent Customer assigned a segment and it went to workflow, mean-while child customer also assigned Efficient Supplier segment and the child customer also went workflow. In this case how to handle
3. UseCases:
   1. Child customer in workflow, and parent is not in workflow: In this case, if the parent customer is trying to add or modify the segments, the system will throw the following Message: ”Updates on segmentation are not allowed for the parent customer since there is at least one child customer that is pending workflow approval.” Suggestion:
      1. Remove the above validation.
      2. Move the parent customer to the parking lot table.
      3. Implement a scheduler to check if all child customers under the parent are no longer in workflow.
         • If all child customers are out of workflow, move the parent customer into workflow for approval.
         • If any child customer is still in workflow, repeat the process until all child customers are out of workflow.
   2. Parent customer in workflow, and child customer is not in workflow: In this case, if the child customer is trying to add or modify the segments, the system will not throw an error. Suggestion:
      1. Move the child customer to the parking lot table
      2. Implement a scheduler to check if the parent customer is no longer in workflow.
         • If the parent customer is out of workflow, move the child customer into workflow for approval.
         • If the parent customer is still in workflow, repeat the process until the parent customer is no longer in workflow.