MuleSoft Accelerator for Retail

Enable a single view of your customer by simplifying connectivity between ERP, CRM, marketing and commerce systems

• Description
• Glossary
• Solution overview
• Assumptions and constraints
• Workflow
• High-level architecture
• Sequence diagram
• Processing logic
• Successful outcome
• Mappings

The Customer Profile Sync use case enables retail developers to create a connected view of customer profiles by unlocking customer data from disparate systems. Simplify connectivity between ERP, CRM, marketing and commerce systems with pre-built APIs, connectors, and implementation templates. This solution streamlines manual processes and consolidates profile data, all while securing sensitive information.

Retailers can connect profiles and build an ID graph to enable activities like unsubscribing to all, which is critical for GDPR compliance, and calculating the total lifetime value of a customer across multiple channels. Of course, a connected profile also allows employees to deliver meaningful interactions both in-store or online.

Description

The customer profile sync use cases enable the creation and updates of consistent and connected customer profiles across relevant applications, regardless of where the starting point of the customer's journey is. They empower you to meet your customer where they are, across market-leading applications in sales, service, marketing, commerce, and all of your additional touch points.

The customer profile sync achieves the following goals:

• Supports the creation of customer profiles across relevant applications, inclusive of Salesforce Clouds
  • Support the creation of Master ID and ID attribution
• Orchestrates controlled profile updates across designated applications
• Accesses customer engagement data across applications

Glossary

Solution overview

1. New and updated customer profiles are captured and published from the following systems:

   • B2C Commerce Cloud - Customers
   • Salesforce (includes B2B Commerce, Sales Cloud and Service Cloud) - Person Accounts (i.e., Accounts with record type Person Account plus associated Account Contact)
   • Marketing Cloud - Subscribers
   • SAP (on a polled basis) - Customers

2. Customer profiles published from step 1 will be recorded in MDM first

3. The MDM master copy will be synchronized with profiles in downstream systems

4. The master identifier will be recorded in all systems, including the system that published the update (if it was not provided)

5. CIM entities supported (system agnostic): Party, Individual, Customer, ContactPointAddress, ContactPointEmail, and ContactPointPhone

6. Primary criteria used to match an existing party in other systems, in order of priority:

   • Master identifier
   • External identifier specific to target system
   • Email Address
   • Customer number
     • Some systems assign a customer number in addition to the internal identifier, which can be used todistinguish between customers in the same system
     • Customer number is not supported by all systems
     • Used only when multiple matches on email address are found
7. In all systems, a new party will be created if not matched to an existing one or if multiple matches are identified
8. Update errors will be reported in the logs and sent to the appropriate dead-letter queue only; no conflict resolution support will be implemented

Assumptions and constraints

• The Cloud Information Model (CIM) will be used as the canonical model for all business types; see the CIM usage guidelines in the Appendix.
• Master identifiers will be maintained in MDM. Wherever possible, these will be assigned as external identifiers in target systems.
• References to the master IDs will be reflected in downstream systems using custom properties to avoid conflicts with the usage of other external identifiers (e.g., global party IDs).
• Updates made in Salesforce will be pushed to MuleSoft via the Push Topic technology.

Workflow

1. Receive a new or updated customer profile from an external system.
2. Attempt to match the input to an existing customer profile in MDM.
3. If a match is found, update the existing entry in MDM. If no match is found, create a new entry in MDM.
4. Publish the update to downstream systems registered for updates.

High-level architecture

Sequence diagram

The diagram below illustrates the sequence of processing customer profile updates to MDM from any external system.

Processing logic

The primary handling and orchestration of customer updates will be implemented in the [Customers Process API]. The logic of this process can be described as follows:

MDM updates

1. Find a matching customer entry in MDM. The lookup will be done by attempting to match on the following criteria, in sequential order, returning once one or more matches have been found:

   • Master Identifier (if provided)
   • External Identifier (of source system)
   • Email Address
   • Customer Number (only if multiple matches found at this point)

2. If a single match is found:

   • Retrieve the existing customer and associated individual
   • Apply the incoming updates and save them back to MDM
   • If not matched on external identifier, associate it with the customer
   • Invoke System APIs to update the downstream systems
   • Associate missing external identifiers back to the MDM customer

3. If no match was found, or if multiple matches were found:

   • Create a new customer and individual entries in MDM
   • Associate external identifier of source system with the customer
   • Invoke System APIs to update the downstream systems
   • Associate new external identifiers back to MDM customer

Downstream system updates

The replication of customer updates to downstream systems follows a similar process as for MDM. The following steps apply to all downstream systems:

1. Find a matching customer entry in the target. The lookup will be similar as for MDM but using the following criteria, also in order by priority:

   • Primary identifier in target system (if one has been associated)
   • Master identifier from MDM
   • Email Address
   • Customer number

2. If a single match is found:

   • Retrieve the existing customer/individual and apply the incoming updates
   • If not matched on master identifier, associate it with the entity
   • Save the updates back to the target system

3. If no match was found, or if multiple matches were found:

   • Create a new entity in the target system
   • Associate the master identifier with the new entity
   • Return the system identifier of the new entity to the parent process

Successful outcome

After successfully completing the update processing for all target systems, the following conditions will be met:

1. MDM holds the master copy of the customer, related individual, and contact information
2. All target systems will hold at least some minimal representation of the same
3. The entity created/updated in each system will reference the master identifier from MDM
4. MDM holds a list of all external identifiers associated with the customer and individual
5. A 360 degree view of the customer can be constructed by first retrieving the master copy from MDM, and then from all associated downstream systems

Mappings

Source-type mappings

The following table summarizes how representations of a customer or individual from each system will be mapped to CIM types:

Target-type mappings

The following table summarizes how representations of a customer or individual from each system will be mapped to CIM types: