. . . . . .

Contact us

Drop us a message by anytime, we endeavor to answer all inquiries within 24 hours on business days.

Email us
Delivery Center (INDIA)

No: 82, 4th Street, Ganesh Nagar, Ayapakkam, Chennai – 600 077, India.


37A Orion Place, Hillcrest, Auckland, 0627, NZ  

Salesforce – Informatica MDM 360 Integration.


Client is, a global enterprise networking company, provides sales and support to business customers and their distribution and reseller network.  As a result of significant growth and acquisition, customer data has also grown above and beyond the current data management processes.  A Customer Master Data Management solution will reduce the amount of duplicate data found in the core systems (SFDC, Oracle/ERP and Zyme/POS) and increase the overall quality and usability of the data.

Informatica MDM – Customer 360 empowers teams with a single view of customers, context of customer interactions, and visibility into customer relationships.
  • Steady State MDM 360 Informatica Integration update process

The schedulable process is required by C360 – SFDC integration implementation for the nightly loads. As part of that, the process is iterating through the records coming from initial response and based on the match records has been inserted/updated at once.

The same logic used for consuming the merged/records used in the Initial Data Update section will be used for the steady state update process.

  • Initial Data Load Process

Purpose of Initial Data Load module is to make MDM 360 Party and Salesforce Accounts data in Sync. There is no sync process in two systems to make data most complete. Automated process to make both the systems up to date has already been covered as a part of MDM 360 Steady State module. In this module (Initial Data Load) the party already residing in salesforce accounts object is old and not in sync with MDM 360 system.


  • To make MDM 360 Party and Salesforce sObjects data in Sync with high data quality and validation based on business rules.
  • Implement automation process to trigger the process based on the frequency selected.
  • Implement Data security and integrity between both systems.
  • Data cleaning and migration between core client systems/services (SFDC, Oracle/ERP, Zyme/POS).


  • Establish and setup communication between multiple systems.
  • Implement validation based on complex client requirement and high level of complexity in existing business rules.
  • Spot check the data and log exception with proper logs.
  • Implementation of retry rules to re-visit the data between multiple systems.
  • Configurable dynamic process to change the frequency of process run based on the requirement and amount of data.
  • Data clean up and migration as part of initial data load process.


MDM 360 shares a WDSL file which is to be consumed by Salesforce to get the meta data required for web service integration. Once WDSL2APEX class is created in Salesforce, make changes in class so that payload is acceptable by C360.A Schedulable process will be scheduled to run in every 24 hours to make communication with MDM 360 to make salesforces Objects in sync based on the match and business rules defined in the system.

A process to call the Siperian Service to get the all BO records created/updated in MDM 360 in last 24 hours. Get all records from 360 MDM and pass it to Steady State batch to process based on salesforce match and business rules defined in the system.

MDM Steady State batch is responsible to process all records in batch to avoid any maximum callout limit in salesforce. Once data is available from response, match the object details in Salesforce with the returned data. Apply rules to it and then insert/update in object. Components to parse the XML MDM response and run the business rules for DML.

The asynchronous process is required by Initial Data Load implementation for the one-time manual run process in Full Copy sandbox. The run extracts all records & related rows from object to iterate through all salesforce objects based on business logic and matching scenarios.

Based on match accounts has been updated and inserted. Since the data load is one-time activity hence our solution is to implement it in Sandbox and then load the data in Production.

This solution does not require any callouts, number of records used from table will already be less for processing due to filtering (filter used would be ROWID_SYSTEM). As this solution will be in sandbox to process data, it does not need deployment. However, the resultant data will need to be uploaded to production upon completion. Final cleaned Account records can be exported and can be reviewed.