There can be a more complex mapping requirement - where data from multiple objects are required to be assembled to send a completed payload to the remote system, or conversely, when the payload from the remote system needs to be mapped into multiple objects in Salesforce. There are many different scenarios that can be encountered, and more specific instructions would be found under the Connector specific guides, but we'll explore a few common cases to illustrate the basic process.
In general, the object mapping will always need to include the 'Base' object. Along with that can be one to many related 'Child' objects and/or 'Parent' objects. The Nexus mapping hierarchy can also track all the way through 'Great Grandchild' and 'Great Grandparent' relationships if it is required to enable such a complex mapping. These types of mapping scenarios generally fall into two categories: one where data comes from related objects, or one that would include a primary record with one to many related records associated to it. The former can usually be accomplished by using the record that would be considered the 'youngest' as the 'Base' object and traversing up through the 'Parent' records using lookups. The latter can happen as an Outbound event, for example a POST to send and Account and a list of related Contacts; or as an Inbound event, for example as a GET on a single account that also returns a list of related Contacts.
Note: Nexus also supports 'List Functions' where instead of being initiated from a single record in Salesforce, a query is used to retrieve multiple records that are used in the API request, but we will cover that later in a separate topic later.
Since we already covered using lookups in the Single Object Mapping section, here we will focus on the parent with a list of child records. To see this type of mapping, access the Connector functions by navigating to the Installed Connectors found in the Nexus Admin page. Select the 'View Connector Functions' from the right-side drop down menu.
Choose 'View Data Events'.
Select 'Record Details'.
Once you see the Details - the Data Event Object Configuration should be set to All Object Types (vs. Base Object Only). This means that the Data Event supports multiple source/destination objects that are involved in the field mapping activity.
When you select the Objects tab - you'll be able to update which objects are included in the mapping. In this case - the objects are Account (as the Base record) and Contact (as the Child record). You can add additional relationships by clicking on the Create New Data Event Object button.
These Object selections allow you to specify which Fields are available for mapping. In this example, you'll be able to update the mapping for fields on both the Account and Contact objects - so that all the fields for the API payload can be identified and mapped accordingly. Because the object selections are defined as Base, Child (in this example), it defines the linkage between the records so that the Child record is linked appropriately to the Base record as a related record. Complete any field mappings that the API requires from the 'Base' Account object.
Now you can select the tab for the 'Child' Contact object. The first thing to do here is to click 'Edit Relationship' and identify the lookup field that connects it to the 'Base' object, which here is 'AccountId'. If the API is looking for a list of Contacts, then this logic is already built into the connector and it will query for all related Contact records and format them into a list for the callout. Continue mapping any additional Data Event Field Maps needed from the 'Child' object.
Note: As Data Event Field Maps are mapped to an Object, then these fields will only appear when that object tab has been selected. Unmapped fields will be visible to all objects. Since the data definitions have been pre-loaded, if you need to un-map a field, remember to edit the mapping and select 'N/A' from the list as opposed to deleting it.
There are some differences in the way you map Inbound events to multiple objects. The 'Base' object may not have anything to update, but you will want to add the list of related objects in the API response. An example of this would be, say, a GET callout to the API that returned contacts for a given Account. To do this, the Inbound Data Event Object creation would still have the Account as the 'Base' object and the Contact as the 'Child', the Outbound would only need the Account. The Inbound mapping could use the 'Reference Only' DML Type for Account and map an id value from the API to a custom External Id field (pictured). Alternatively, the OriginatingRecordId would also be an option (not pictured). If there are other fields to update on Account, then the DML Type can still be 'Upsert'.
The DML Type for the 'Child' Contact would be set to 'Insert' (or 'Upsert' if an External Id was available in the API response). The Relationship Lookup Field would be the 'AccountId'.
Even though the Relationship with the Parent Account record has been identified, there will still need to be a Data Event Field Map on the Contact that populates that value on each of the related Contact records. In this case, since there is no field in the API Response that has the Salesforce Id, we can click the 'Create New Data Event Field Map' button, leave the Inbound Field Name blank, but choose 'AccountId' as the Salesforce Filed API Name. A new select box will render for the 'Related Data Event Object Existing' where you can select the 'Account - Base' option and click Save. When the Salesforce record(s) are created, the system will use the Id of the 'Base' record it found to relate the 'Child' records. Continue mapping the rest of the 'Child' Contact fields as desired.