Blog Detail

Most Common Challenges in Salesforce Integration

28 Mar

Businesses today use multiple applications for different purposes like Sales, HR and Finance, Operations, Service, etc. to enhance their operational efficiency. Most of these applications are used to resolve business complications and issues, but the problem is they don’t talk to each other. This develops into a siloed architecture where the crucial customer information is fragmented and preserved. Salesforce thus serves as a consolidated customer data location, and hence it makes sense for companies to enable its integration with the existing platforms seamlessly.

Salesforce integration caters to different layers, like Identity, Data, Process, and presentation layers. Salesforce provides flexible data security model to secure data at different levels like object level, record level, and field level security. Salesforce integration syncs data and helps in maintaining the data consistency between multiple applications and Salesforce.

But this integration may not be as easy as it sounds. Or, is it? Let’s find out the most common challenges encountered by companies while integrating multiple business applications/external systems with Salesforce.

1. Data Mapping

The most common issue of data mapping encountered during Salesforce integration is the mismatch of data and field types. The field types vary from one application to another. For instance, the address fields in Salesforce may be given as street, state, city, etc. but the other application may not have the exact same fields. Writing code in such scenarios could become an additional effort making data mapping a tedious job.

As part of field mapping, we must ensure to map the right field type or convert data to a target app supported field type to map the relevant data. By doing this, you may avoid the trouble of converting all field types to target app supported field type.

2. Duplicate Records

Duplicate records are a challenge faced by all companies that lead to bad data. It’s important that you have a system which identifies and limits the entry of duplicate data during integration.

When importing custom objects, solution, or person accounts, you can use external IDs to prevent the import from creating duplicate records. An external ID is a custom field that has the External ID attribute, meaning that it contains unique record identifiers from a system outside of Salesforce. When you select this option, the import wizard detects existing records in Salesforce with external IDs that match those values in the import file. For example, a company wants to integrate data between its Oracle Financials System and Salesforce. It becomes easy for the company to refer the Oracle ID records within Salesforce rather than referring Salesforce IDs. Leveraging the External ID to upsert (insert or update) the records into Salesforce helps in removing duplicate data.

Note: Using the Data Import Wizard, import up to 50,000 records at a time. Importing too many records can slow down your org for all users, especially during periods of peak usage.

3. Auto-ID Creation

Another thing to keep in mind is that Salesforce automatically generates its ID for each entity created or imported into it. It is a problem when the records, imported from external applications already have IDs and are linked to other records via those IDs. Meaning, when we import records from an external system to Salesforce, it manages two sets of IDs in Salesforce (Salesforce Record ID, External system ID). Eventually, the external system IDs are lost if Salesforce overwrites the IDs.

E.g. if an external ID is overridden in Salesforce, we lose the reference to the record in the external system. However, we need to avoid this by adding some configuration (make external ID unique and required at field level) and validations/custom logic to prevent overriding of external IDs.

4. Data Migration

Data migration is one of the severe problems during integration because data storage may vary based on the Salesforce edition. If the external application has duplicate records, importing the data will result in transferring those duplicate records into Salesforce.

However, to avoid generating duplicate records, we can leverage the Salesforce out-of-the-box features (Duplicate Management) or define a custom code. Also, External ID (Unique Id) will play a key role in data migration as it would be the actual field to identify to create/update records during the Salesforce migration. In addition to the above, defining right access control (FLS – Field-level Security) in Salesforce will result in proper data migration. Like, defining relevant access to fields instead of proving access to all the fields while migrating data into Salesforce.

5. Defining the Scope Precisely

Salesforce benefits are best leveraged when integrated with other applications/business systems in the organization. Salesforce supports SOAP/REST services, and hence, it’s essential to understand the scope of integration – whether to expose a service in Salesforce or consume external service.

We may not always have to expose a service from Salesforce for real-time data because of out-of-the-box rest endpoint. Every object in Salesforce has a default rest endpoint that avoids writing custom code in Salesforce. Authentication with Salesforce is also pre-requisite for integrating Salesforce with other systems.

6. Promoting Bad Data

Propagating bad data into Salesforce from an external system is not good. If the external system pushes old records or unnecessary information into Salesforce, it will result in data duplication. It is essential to remove obsolete data and cleanup systems in external systems before integrating with Salesforce.

However, we have other ways to avoid the creation of duplicate records in Salesforce which always counted against additional efforts – like, leverage Salesforce Out-of-the-box features like “Duplicate Management” or a piece of code.

7. Misinterpreting Real-Time Integration

It is a wrong assumption to think that importing or exporting of data from Salesforce is the same as real-time integration. Usually import/export of records run as batches and data may not be immediately synced compared to real-time integration. Hence, Salesforce/external applications would be out-of-sync for some time until executing the batch.

8. Data Rate Limits

Since Salesforce runs in a multi-tenant environment, it strictly enforces governor limits imposed by Salesforce APIs that determine data access – concurrently in a single call and one day. Hence, going beyond these limits results in Salesforce run-time errors during the process. It is essential to understand the restrictions enforced by Salesforce while implementing the solution to avoid any issues.

9. Identifying Accurate OOB Features/ Connectors

Before deciding on Salesforce integration, it is required to identify whether the requirements can be met with out-of-the-box Salesforce features or connectors and leverage them rather than writing the code.

For instance, if you have data stored on premises in an ERP system, instead of copying data into your Org, you can leverage External objects. They are available with Salesforce to connect and associated with the external data source. External data source specifies how to access an external system. External objects are similar to custom objects but record data that’s stored outside your Salesforce Org. External objects are best used when you have a huge volume of data that cannot be copied into Salesforce.

10. Choosing Right Apps on AppExchange

It is imperative to identify the right application from AppExchange (Free/Licensed) that meets your business needs, for Salesforce integration. Choosing the right app will reduce development efforts and saves your team’s time and efforts. If none of the apps satisfy your set of requirements, it is suggestable to build your integration.

Also, apps available on AppExchange are available as managed/unmanaged packages. Please note that you can make changes to the unmanaged package and not to managed packages.

11. Data Validation

Data validation is one of the key aspects while populating the data from an external system to Salesforce. Especially when you are filling data into Salesforce standard objects.

E.g., to create a contact in Salesforce the field the last name is mandatory, and the record will be successfully updated only when these mandatory fields are populated. All the contacts from the external system should satisfy the validation criteria to sync the data into Salesforce. The same validations apply to all custom objects too.

Also, it should be noted that some fields may be mandatory in Salesforce but optional in external systems. So, it is essential to understand the impact of any changes done at data validation level.

12. Start with Clear Integration Scope

Never start an integration without a precise scope. It’s always a best practice to have some insights on external systems and Salesforce before you kick-off the integration as you know Salesforce strictly enforces governor limits. Be ready with expected documentation and other business process details to kick-off the integration.

13. Partial Decision Making

Setup a kickoff call with the right people to review the information collected during the meetings. Also, analyze the costs involved in the case of software updates and upgrades as it may affect integration.

14. Understand Objects Relationship

It is essential to understand the relationship between objects in Salesforce and external systems. Because while syncing data between the systems you would be selecting the right object in Salesforce for a relative object in an external system like selecting standard or custom object in Salesforce.

Conclusion:

Make sure to consider the above points while integrating Salesforce with any third party/internal business systems. Think of leverage out of the box features or any app exchange apps that suit your requirements rather than building your own integration. If it is decided to leverage any app exchange app or OOB feature it is essential to understand the limitations of apps and Salesforce.

About Solunus:

Solunus, a North-American based Salesforce Gold Partner, prepares businesses for their next-generation customers. Established in 2014, we simplify Salesforce for you to build more meaningful customer relationships. We partner for a win-win arrangement with clear ROI that the client realizes by the end of the engagement. Our 350+ years of cumulative industry exposure and Salesforce experience underpin our position as the right Salesforce partner. We are a team of Salesforce Certified Professionals, CRM Architects, and certified Agile Scrum Masters with a passion for making a difference.

About the Author:

Rajeshwar brings his 11 years of experience to Solunus. He is skilled at various technologies – cloud (Salesforce), integration of third-party/internal systems and web technologies (Java/J2EE). He is a Force.com certified app builder, developer, administrator, and consultant. He has worked with MNCs like Accenture and Capgemini in the past.