Salesforce Integration: What Could Go Wrong?
It doesn’t matter whether you represent a company from the InsurTech, WealthTech, or any other sector of the FinTech industry. You need CRM. You might develop it in-house or integrate your system with an existing CRM platform such as Salesforce, which is one of the most popular choices.
Salesforce designed a financial services cloud platform specially for the financial industry that has additional specific objects. This is great, but Salesforce integration still comes with pitfalls that can cause headaches — or worse — for developers, platform owners, and even clients.
We have prepared a detailed whitepaper in which we analyze the risks that integration with Salesforce can pose and explain how to avoid them. You can download the whitepaper here. Below, we will offer you an overview of the main risks you should consider before you start the Salesforce integration process.
Significant rework due to inappropriate data-mapping
Salesforce has standard objects within its fields including
Opportunity, and many more. Their financial services cloud includes objects such as
AssetsAndLiabilities, and so on.
Despite this range, it’s more than likely that Salesforce’s objects don’t perfectly align with those of your system. Before you start the integration process, consider data-mapping between Salesforce and your core platform. If there’s no acceptable standard object in Salesforce, you can create custom objects or supplement standard objects with custom fields.
Without preemptive data-mapping, you might discover new connections and dependencies when it’s too late. After the integration process has started, your developers might need to do significant rework to include everything that has been missed.
Our whitepaper contains links to the lists of standard Salesforce objects and requisites for custom objects and fields. There, you can also find an example of mapping of a simplified data model for a FinTech platform.
Blocked integration due to exceeding limits
Salesforce imposes limitations on runaway code, processes, API requests, and loads of financial services cloud records. This ensures that a process doesn’t monopolize shared resources. Limitations include the following:
- A maximum number of callouts that a single transaction can make
- A minimum and maximum timeout for callouts and transactions
- Timeout limits based on CPU usage
- The total number of allowed SOQL queries
Once the limit is reached, integration will be blocked until the end of a 24-hour period. This means that your platform users will have no access to their data stored on Salesforce during this time. Some limitations depend on whether your requests are synchronous or asynchronous and on the Salesforce edition.
Our whitepaper includes detailed information about limitations and advice on how to avoid blocking.
Data damage or loss due to poorly formulated rules
Temporary blocked data isn’t your biggest concern. It’s much more dangerous to lose data or damage them irreversibly. This is why you should define rules for updating data within the preliminary business analysis. Discuss the following:
- Should data be synchronized one way (from Salesforce to your platform or vice versa) or two ways?
- Which data do you consider as relevant (e.g., data that were updated later or data that are stored on a particular platform)?
- In what cases might dataflows conflict, and what should be done then?
- Should you overwrite deleted or null values?
- Which objects should be synchronized and how often?
In our whitepaper, we offer you examples of object- and field-level one-way data-update rules.