Frequent “gotchas” of integrating FinTech platforms and Salesforce
I’ve interviewed people from numerous FinTech platforms, each with their own history and business model. Despite their differences, in almost all conversations, they addressed integration with customer relationship management systems (CRMs). CRMs enable FinTechs to systematize client information and allow clients to apply proper communication strategies. Salesforce is one of the most popular options out there: it’s been on the market for a long time, has all the most coveted features, and provides a customized solution for financial startups—Salesforce Financial Services Cloud (FSC). Undoubtedly, Salesforce integration is a must, despite the high risk of pitfalls.
The most important part of any work is planning, isn’t it? Thorough thinking over the integration process aspects and business analysis enables to escape rework, limitations blocks, or even damaging customer data due to inappropriate data update rules. What can you do to emerge unscathed? Let’s go through the possible pitfalls of integrating Salesforce.
Data mapping “gotchas”
There’s a fat chance that your system’s entities will replicate those of Salesforce. FSC provides an extended list of standard objects containing many of those you might be missing. Still, defining custom objects and fields might be necessary, and you might need to do significant rework during or after the integration process if entities have not been mapped thoroughly beforehand.
The standard objects supported by FSC can be found in the Salesforce Developer Documentation and Financial Services Cloud Developer Guide. For example, standard business objects such as Account, Contact, Opportunity, and many others are standard, whereas financially specific fields like FinancialAccount, FinancialGoal, Securities, and AssetsAndLiabilities occur only in the extended package. Still, if none matches a core platform object or field, Salesforce allows you to define custom ones based on some requisites.
This example shows how the existing data model can be mapped to Salesforce.
The detailed requisites and visualization techniques to avoid data inconsistencies can be accessed in our how-to guide on Salesforce integration.
The importance of business rules
The data will be updated within Salesforce and core platforms, so it’s crucial to predefine the rules of data sync to avoid corruption. CRUD operations rules at Salesforce are divided into two categories: object- and field-based. This is because during special cases of synchronization, operators often don’t pay enough attention to generalized merge strategies such as one-way sync (Salesforce→core platform or vice versa), the newest data priority, a specific user’s modification priority, etc. Special cases comprise actions with null or empty fields, existing and missing entities, priorities during incremental sync, and conflicting sync settings. Once you ignore them, your dataset is filled with outdated and corrupted fields, thus discreetly downgrading its potential quality.
Mapping your business rules starts with depicting object scheme and specifying special cases by assigning its own configs. to prioritized fields.
Object-level one-way object mapping (i.e., data flow from Salesforce to core platform)
With two-way synchronization, the rules become much more complicated. Salesforce and the core platform might have their own configs. on the object and field levels, and these might compete with one another.
How do you cope with such complex data mapping? First of all, make sure you read Salesforce mapping documentation as well as listed all the rules. To easily set up rules within FSC, use “Update Rule Edit” form.
Salesforce limitations
To ensure that a process doesn’t monopolize shared resources, Salesforce imposes limitations on the number of API requests, runaway Apex code, loads of FSC records, etc., depending on the Salesforce edition and whether synchronous or asynchronous Apex is used. Apex is an OOP language for executing flow and transaction control statements on Salesforce servers. Its syntax looks like Java; Apex enables developers to insert, update, delete, or restore data in the database using the Data Manipulation Language (DML).
Once the transactions, records, or loads limit is reached, the integration will be blocked until the end of a 24-hour period, thus imposing great damage to the platform’s workflow. Examples of limitations can be found here.
What should you do to mitigate Salesforce integration blocks? First, read Financial Services Cloud Limitations and Salesforce Developer Documentation carefully. Also, make sure your Salesforce Edition licenses are in line with your system’s architecture. If you want more guidance, examine “Bulk API” or apply large data volumes loading techniques.
What else to consider
All the details regarding Salesforce integration for a financial space are now available in a complete how-to guide. There, you’ll access the following recourses:
- Real integration case studies with data-mapping schemas
- About two dozen links on documentation catalogs, best code practices, useful appendices, and cases aimed to help you succeed
- A detailed Apex overview that will guide you through its pros and cons, ways to perform DML operations, and usage examples
Download your copy here.
