In scenarios where Salesforce is to be considered as the data master for customer information, connected system identifiers can be represented as either custom fields on a particular record, or as a custom object associated with the record.
For example, a contact record in Salesforce is the golden record for data relating to a person across a company’s enterprise. In order to ensure associated records are correctly updated when data in Salesforce is updated (such as HR system data that shouldn’t reside on Salesforce), a middleware platform (such as MuleSoft) will need to interrogate Salesforce to determine the associated systems and record identifiers in those systems that require updating when the contact record is updated. This essentially adds a round-trip into data update or retrieval operations, as IDs in Salesforce need to be queried to know which associated system records to affect.
The following diagram shows an example of how this may be sequenced when Salesforce holds the record associations:
Figure 3.2 – Salesforce holding the golden record associations
In the next section, we’ll take a look at the representation of a golden record when middleware holds the record associations.
Taking our example from the previous section, if the middleware (such as MuleSoft) holds golden record associations, we can essentially have Salesforce only care about itself in terms of record integrity, with the onus being passed to the middleware to ensure that data operations to or from associated systems are correct. This does reduce the initial querying of Salesforce to determine those associated system IDs, but an additional process needs to be put in place to ensure that the middleware is updated appropriately if an associated system is added to, or removed from, the IT enterprise.
The following diagram shows an example of how this may be sequenced when middleware holds the record associations:
Figure 3.3 – Middleware holding the golden record associations
Next, let’s look at the representation of a golden record when a separate system or external registry holds the record associations.
Requiring a callout to another separate registry system or similar (typically orchestrated through the use of middleware, such as MuleSoft), the golden record doesn’t necessarily know what records constitute it, and therefore, a registry of identifiers to piece together record information is used to then orchestrate the callouts to other separate systems. This action could be initiated by Salesforce calling the middleware to piece together a golden record using the Salesforce record ID, which is then referenced in the registry system to orchestrate a number of system callouts and process the returned data back to the user. Alternatively, middleware, or a batch-processing system, could orchestrate data updates into the golden record on a scheduled basis.
The following diagram shows an example of how data updates may be sequenced when a separate system holds the record associations:
Figure 3.4 – Querying an external registry for the system identifiers associated with the Salesforce record
Of course, sometimes you may wish to use data that is kept outside of Salesforce.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
