By: Ajay Shukla, Principal – Data Engineering, Ltimindtree

1 Introduction

Informatica’s Intelligent Data Management Cloud (IDMC) platform offers Master Data Management (MDM) services such as Customer 360, Supplier 360, Product 360, and Multidomain MDM for managing master data. It supports field-level data quality (DQ) rules and Data-as-a-Service (DaaS) for enriching fields like address or email. However, it lacks real‑time enrichment through third‑party data providers such as D&B or IQVIA and cannot auto‑populate user‑defined fields that rely on complex business logic. This limits the scope of an effective data enrichment framework, especially when organizations seek automation and accuracy in data workflows.

2 Current state of affairs

Many organizations must enrich the existing master data by using simple keys—name, D‑U‑N‑S number, or similar identifiers. Typical use cases include adding a legal name, hierarchy, contacts, or other details that require near‑real‑time enrichment. A healthcare example illustrates the need. Given a National Provider Identifier (NPI) number, the system should enrich a healthcare organization (HCO) with its legal attributes like name, alternate name, key executives, practice locations, mailing addresses, taxonomies, and identifiers. The same applies to health care personnel (HCP) records that need prefix, suffix, gender, or taxonomy data. Product records face a similar challenge when only a SKU is supplied.

Similarly for persons, there can be a business requirement to derive unique ID, based on some pre-defined business logic, dependent on other field values. For example, if the business address provided for the record is a USA-based address, then the customer ID should be generated in the format of “CUST-US-00001”. If it is based out of India, then the customer ID should be generated in the format of “CUST-IN-00001”. In this case, as the address belongs to a different field group and customer ID belongs to root field group, it is not possible to define a data quality rule.

This can be termed as current behavior or tool limitation often found in legacy master data management systems.

3 Solution

One of the ways to achieve near-real-time data enrichment and business-entity-level field access, is by setting up an asynchronous enrichment process. This approach ensures keeps a record inactive until every required field is populated according to business rules.

Many organizations, including LTIMindtree’s insurance practice, have created the need for such functionality by building an IDMC-native extendible data enrichment framework. Because the framework runs entirely within IDMC, no additional servers or external components are required.

The accelerator relies on IDMC’s Cloud Application Integration (CAI) service. CAI is invoked when a business event such as the creation of a business entity—is triggered by clicking send for approval. Before activation, administrators must configure the necessary Business Events for each create or update action on entities that will be enriched.

3.1 IDMC native

Because the framework is native to IDMC, it needs no third‑party components, servers, or tools. Deployment is straightforward: import a single ZIP file into any target IDMC instance.

3.2 Prerequisites

To deploy and operate the framework, meet the following requirements:

• Access to an IDMC instance with valid user credentials
• Read‑write privileges (via role or group assignment) on the business entities to be enriched
• Read privileges on IDMC users and Master Data Management (MDM) metadata
• Updated credentials in the application connector acMDMTaskApis
• All framework assets imported and published after deployment
• Business events configured for entity create and update actions, with the custom workflow selected as the process and task details—approvers, labels, and pages—defined

Some screenshots are listed below as reference:

Figure 1: Pre-requisite configuration for Business Events | Source: LTIM IDMC instance

Source: LTIM IDMC instance

3.3 Architecture

The framework operates as a CAI process that contains several subprocesses and decision trees (Figure 2).

Figure 2: Master Process | Source: LTIM IDMC instance

Source: LTIM IDMC instance

This modular design aligns with the best practices followed in scalable master data management systems, enabling smooth orchestration and governance. The main process is named as “prcEnrichBEAsynchronously” which starts whenever an associated business event occurs.

A logical flow of steps is depicted below:

Figure 3: Logical flow | Source: Locally created

It invokes two sub-processes namely:

1. prcGetWorkflowDetails: It is used to fetch workflow associated details like workflow triggered for which business entity’s name and its metadata, business entity’s record ID, business event ID, event action, and invoker user details. All these are part of this workflow.
2. prcUpdatePendingPersonBE: It is used to:
3. Parse person record (which was submitted by a user)
4. Extract required field values
5. Generate customer ID based on business logic
6. Update pending person’s record by populating the title field with generated customer ID

All required deployment assets are shown in Figure 4.

Figure 4: Dependency list of assets | Source: LTIM IDMC instance

The framework calls IDMC login, logout, metadata, and record‑fetch application programming interfaces (APIs) through the service connector ‘scMDMTaskApis’. Any external APIs are called through ‘scPublicApis’.

It also leverages the XQuery language supported by CAI to enable the use of various expressions for variable initialization, derivations, list processing, and assignments.

4 Barriers and success stories

4.1 Barriers

Some of the APIs used in the service connectors are private, hence there may not be much documentation available on them.

4.2 Successful sample record enrichment examples

4.2.1 UseCase_1: Organization with IFSC code HDFC0000239

No organization records initially contain names starting with HDFC.

Source: LTIM IDMC instance

An organization is created with HDFC0000239 as the name via the Customer 360 service. Only the name and number of employees are provided.

Source: LTIM IDMC instance

After submission, the framework enriches the record with the correct branch name, address, and phone number (Figure 5).

Figure 5: Organization enrichment based on code | Source: LTIM IDMC instance

4.2.2  UseCase_2: Person with USA postal address

No person named Ajay exists.

Source: LTIM IDMC instance

Then, a person record for Ajay is created with a USA address, using the C360 service. Note that the title is not populated.

Source: LTIM IDMC instance

After enrichment, the title field holds a U.S.‑formatted customer ID (Figure 6).

Source: LTIM IDMC instance

Figure 6: Customer Id based on USA address | Source: LTIM IDMC instance

Source view of the record shows that the tile field is patched with the generated ID.

Source: LTIM IDMC instance

4.2.3  UseCase_3: Person with India postal address

Creating new Person record for Ajay, with address as one from India, using C360 service. Note that the title is not populated.

Source: LTIM IDMC instance

The below image shows that a record is created after submission and enrichment.

Source: LTIM IDMC instance

Then, a record’s title is populated with customer ID, which is specific to the country, India.

Figure 7: Customer ID based on India address | Source: LTIM IDMC instance

4.2.4 Use Case_4: Person without any postal address

Creating a new person’s record for Ajay, with no address, using C360 service. Note that the title is not populated.

Source: LTIM IDMC instance

The below image shows that a record is created after submission and enrichment.

Source: LTIM IDMC instance

Next, a record’s title is populated with a customer ID, which is default. This can be further customized based on the client’s needs.

Figure 8: Customer Id without any address | Source: LTIM IDMC instance

4.2.5 Use Case_5: Creating organization via API

First, Create an API request for an organization with the name (IFSC Code) as SBIN0016719.

Source: Local postman

Next, a record is created successfully.

Source: Local postman

Then, fetch the record by an API to verify the name, address, and phone number.

Figure 9: Org details enriched via external API | Source: Local postman

4.2.6 UseCase_6: Creating Person via API

Create an API request for a USA-based person’s record.

Source: Local postman

Next, the person’s record is created successfully.

Source: Local postman

Finally, fetch the record through an API to verify the customer ID value for USA’s country code.

Figure 10: Customer Id generated via API | Source: Local postman

These use cases illustrate how asynchronous enrichment can handle diverse business scenarios—from country-specific customer ID generation to external API–driven validations. The framework adapts seamlessly across data domains and operational models, offering both precision and flexibility for enterprise-scale deployments.

5 Conclusion

The IDMC Asynchronous Automated Entity‑Enrichment Framework—implemented by several service providers, LTIMindtree among them—enhances master data management system capabilities through asynchronous processing and complex business logic. Fully native to IDMC and requiring no external components, the framework ensures that records are consumable only when all key fields are populated. Built‑in logic, reusable components, and XQuery support make it both customizable and extensible. Proven use cases across organizations, persons, and products demonstrate the framework’s ability to overcome current platform limitations, set a benchmark for near–real‑time enrichment, and significantly boost IDMC’s data‑management capabilities.