The Pendo Salesforce integration uses the Salesforce API to both pull Salesforce data into Pendo and to push Pendo data into Salesforce. One of the first components of the process is an SQL query that runs against the Salesforce API. The query first gets all of the possible records from your SFDC instance that contains a value, regardless of whether those records exist in Pendo. In some cases, with a large number of records, that query might timeout causing the sync to fail. You may see the timeout logged as an error on the Error Log page with an error of timeout awaiting response headers.
For example, if you are using the contact object in Salesforce to sync visitor data and syncing based on a field in that object (e.g. email address), the first query that Pendo runs will try to pull in all contact records that have a value in the field you are using for mapping - regardless of their status as an active customer - which can result in a very large query.
Optimizing the Configuration
By optimizing your configuration, you can reduce the number of records returned in the query by only including active records that you wish to sync.
There are two main options for optimizing your configuration and reducing the likelihood of generating this timeout error: 1) adding a new formula field or 2) using a custom object. Both of these options work by limiting the total number of records that the Pendo integration 'sees' in your Salesforce instance to only active records that need updating. Both of these are Salesforce-side implementations and would require assistance from your Salesforce Admin.
While the examples below are based on syncing visitor-level data, the same options also apply to account-level data.
Option 1: Formula Field
In order to reduce the number of records returned in that initial query, you may want to implement a new field for the mapping. That field will ONLY be populated with data for active users in your application.
For example, let's say that you have selected to sync based on the contact object field of email address. Right now that field populates with the contact's email address regardless of whether or not they are a customer, prospected, or churned user. To reduce the query size to only active customers, you could create a new field on the contact object that uses a formula to determine a contact’s status. If they are active, then the new formula field populates with their email address.
This new field in Salesforce will now only populate when the contact is an active customer and can be used for mapping the respective field (e.g. email address) to Pendo. Now when Pendo runs the initial query we will pull a list of contact records that have a value in that newly created field (and skip the ones that do not). Because you set this via a formula field (that is checking some other data point in Salesforce to determine if they are an active customer) the field will depopulate if the contact becomes inactive.
Connecting your Pendo field with a formula field can greatly reduce the number of records in the initial query by limiting that query to only the 'active' records of that object type.
Option 2: Custom Object
Alternatively, you can reduce the number of records returned in the initial query by implementing a new custom object that only holds records for active users or accounts. This solution requires creating a new Salesforce object that represents only active customers/accounts.
Rather than using an SFDC default object (like the contact object) that usually contains both customers and prospects you could create something like a custom user object in Salesforce. This custom object would populate with many of the same fields as the contact object, but records would only exist for active customers.
First, create the new object and then add all of the fields to that object that you would like to pull into Pendo. Next, update your SFDC integration settings from the data mappings page in Pendo to point to the newly created custom object. The initial query should be much smaller than using an object that has both active and inactive users because that object only holds records for active customers.