fbpx

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.

Salesforce Integration mapping
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.

Salesforce integration Mapping rules
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.

How to Avoid Overspending on Amazon Cloud

How to Avoid Overspending on Amazon Cloud

In this modern world of digital transformation—especially in fintech, where financial institutions are forced to adopt cloud for the sake of saving competitiveness with start-ups—overspending cloud budgets seem shocking. However,…

When Salesforce Integration Becomes a Problem

When Salesforce Integration Becomes a Problem

B2B WealthTech software providers integrate with Salesforce to make their own platforms more attractive for existing and potential users. In today's article, we look through pitfalls in the Salesforce integration…

Pitfalls of Integrating WealthTech Platforms

Pitfalls of Integrating WealthTech Platforms

The industry requires all FinTech players to be flexible, integrable, and snap-in. In this article, we pay attention to integrating platforms through API because it’s the most widespread type among…

Are Hadoop and Spark Silver Bullets for Financial Market Data ETL?

Are Hadoop and Spark Silver Bullets for Financial Market Data ETL?

Robo-advisors are platforms with rapidly growing data pools. The efficiency of a particular robo-advisor depends on the number of securities covered (scope) and the historical depth (number of years) of…

Databases Used by Robo-Advisors (Infographics)

Databases Used by Robo-Advisors (Infographics)

Robo-advisors’ functioning is based on algorithms that allow platforms to suggest investment strategies based on large amounts of data which is received from different sources. Thus, robo-advisors use various data…

Technologies Used by Robo-Advisors for Frontends (Infographics)

Technologies Used by Robo-Advisors for Frontends (Infographics)

To create frontends for robo-advisors, generally, frameworks, such as AngularJS and React, are used. Unlike most frontend frameworks, PHP performs server-side operations in addition to the client-side script. This is…

Technologies Used by Robo-Advisors for Backends (Infographics)

Technologies Used by Robo-Advisors for Backends (Infographics)

The efficiency of robo-advisors generally depends on algorithms selected. However, technology stack used for the software platforms has a significant impact on satisfying clients’ expectations such as the system performance,…

Microservices Architecture for WealthTech Projects

Microservices Architecture for WealthTech Projects

Nowadays, robo-advisors have become widespread. These services enable people with relatively low-value investable assets to benefit from online finance and portfolio management. Robo-advisors are automated tools that use a variety…