Summary
Extension objects are Salesforce objects with a relation to a parent object
Their purpose is to add additional information to the parent (e.g. you might have a custom "Account Extension" object to supplement the Account object)
You can sync them in the Salesforce integration - this means you would have multiple Salesforce objects mapped to a single Planhat model
The extension object should only have 1 record (e.g. Microsoft Extension) per parent object record (e.g. Microsoft) for the sync to work correctly
Who is this article for?
It's for Planhat builders (e.g. CS Ops) or Salesforce admins configuring the Salesforce integration
Series
We have a series of articles on the Salesforce integration:
Extension objects in the Salesforce integration β¬ οΈ You are here
Article contents
Click below to jump to the relevant section:
Introduction
This is a technical deep-dive article
Read on if you'd like to explore the details of extension objects in the Salesforce integration.
If you'd just like an overview of the Salesforce integration, please refer to our main article.
The Planhat Salesforce integration is compatible with extension objects. This means you can connect multiple Salesforce objects to a single Planhat model.
The Salesforce extension object needs to have at least one field referencing the object you want to extend. For example, you could use an "Account Extension" object (custom object) with a lookup field to Account, or a "Contact Extension" object (custom object) with a lookup field to the Contact.
π Definitions
An "object" in Salesforce is the metadata container - e.g. Account or Contact
The Planhat equivalent is "model" - e.g. "Company" or "End User"
A "record" in Salesforce is the data inside the object - e.g. within the Account object, records could be "Apple", "Microsoft" and "Google"
The extension object needs to have a 1:1 relationship with its parent object when it comes to its records - that means there's 1 extension object record (e.g. Apple Extension) per parent object record (e.g. Apple).
The typical use case is that the extension object is "enriching" (adding extra detail to) the main object (and hence the connected Planhat model).
π Important to note
You can't have an extension object for the License and NRR (Sale) Planhat models.
Main principles
Generally in the Planhat Salesforce integration, you have one object in Salesforce (e.g. Account) connected to one model in Planhat (e.g. Company). This means you have one record in Salesforce (e.g. Account A) connected to one record in Planhat (e.g. Company A).
But sometimes, you might want to connect an additional object/record in Salesforce to an object/record in Planhat. An example is if you have reached your Account field limit in Salesforce, so you create a custom object called "Account Extension", with a lookup field to Account. It's possible to sync this into Planhat too. The "Account Extension" custom object is an example of what we are referring to when we talk about "extension objects".
There needs to be a 1:1 relationship between the objects in Salesforce - so in this example, there is 1 Account Extension record per Account record. The extension object is not suitable for the sync if there is a many-to-one relationship, with potentially multiple extension object records per parent object record. So, for example, you could have the Tesla Account with a single Account Extension record, but if the Tesla Account was connected to two or more Account Extension records, the sync wouldn't work properly.
If you do have a setup like this, only one extension object record would be synced, but it's random which one it would be - so in the example above, it could be Account Extension A, or Account Extension B.
However, it is possible to sync an additional extension object to the same model in Planhat, if required. Note that once again, this object must have a 1:1 relationship with the parent object - meaning that there is only 1 record of this other extension object per record of the parent object (e.g. Account). This different extension object would need to be configured in a separate section of the Salesforce integration than the first extension object - more on how to set up extension objects in the integration later.
Source IDs
Background
Models in Planhat have a built-in "source ID" field/property. When you sync data records into Planhat from your CRM software, this field is populated with the ID from that CRM - in this case, Salesforce. So, for example, when a Salesforce Account is synced into Planhat, the resulting Planhat Company will have the Salesforce Account ID automatically added to its source ID field. The source ID is how Planhat knows which record in Planhat is mapped to a specific record in Salesforce, and vice versa.
Source IDs for extension objects
Let's continue with our example of mapping the Salesforce Account object and a custom object called Account Extension.
As we've just described above, the Salesforce ID for the Account will be automatically added to the source ID field on the Planhat Company, so Planhat can identify the Account/Company pair - e.g. Account A is mapped to Company A in our diagrams above. So what happens with the Salesforce ID of the associated Account Extension record (Account Extension A in our diagrams above)? This Salesforce ID can't also be mapped to the source ID in the Company, as that can only store one ID.
The solution is for you to create a custom field on the Company model for the extension object's ID, called "Extension object source ID" or similar.
When you configure the extension object in the Salesforce integration, you then select this custom field as being the source ID reference - we show this in the next part of this article.
If you want to connect an additional extension object to the same model (note here we are talking about objects rather than records - so the bottom diagram above), you would need to create an additional custom field on the parent model to map to the Salesforce ID (source ID) from this other object.
Configuring extension objects in the Salesforce integration
There isn't a default section of the integration for extension objects; you create them by adding an "extended mapping" section at the bottom. Just click the blue "Add New Section" button at the bottom of the integration to add a new section to fill in.
π Important to note
If you can't see the "Add New Section" button, that indicates this functionality is not currently included in your subscription. If you would like to map an extension object, reach out to your CSM to review your package.
The section will look something like this:
You can click on the image above to enlarge it, but below we'll zoom in on a couple of key points:
We talked about source IDs earlier in this article. Here, on the left-hand side (the Planhat side), use the dropdown to select the custom field on the Planhat model which will contain the source ID (Salesforce ID) of the Salesforce extension object.
On the right-hand side (the Salesforce side), use the dropdowns to:
Select which object the extension object is related to (parent object)
Select the field on the extension object that links to the parent object
You can configure custom field mapping for this extension object section, similar to other model/object pairings you will have set up in the rest of the Salesforce integration.
π Tip
If you want to add a second extension object for the same parent object, simply click the blue "Add New Section" button at the bottom again, and configure that section like we have described above.
Syncing data from Planhat to Salesforce
Let's take the advanced example where the Company model in Planhat is mapped to 3 different objects in Salesforce: the Account object, and 2 custom objects called "Account Extension" and "A Different Account Extension". If you make an update in Planhat to a particular Company, does this feed to 1, 2 or all 3 of the connected records in Salesforce?
The answer is that it depends on how you have set up the custom field mapping for each object in the integration. Have you listed the relevant field in the field mapping section, and turned on the sync via the sync direction (i.e. set it to "Both Directions" or "Send to Salesforce")?
If you update a field on the Company in Planhat, and the integration is set up to send that field to the Account object, but it's not included in the field mapping for either extension object, then that update will be sent to the Account in Salesforce but not to the extension objects.
Or, if you update a field on the Company, but this time you've configured field mapping for it for one of the extension objects (e.g. you map a custom Company field called "Account Extension Name" to the "Name" field of the Account Extension object) but not the other and not the Account, it will only send the update to that configured extension object.
You get the idea! π