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.

1. Most Common Challenges in Salesforce Integration
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 a flexible data security model to secure data at different levels like object level, a
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.

2. 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 types.
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 that identifies and limits the entry of duplicate data during integration.
When importing custom objects, solutions, or personal 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 to
the Oracle ID records within Salesforce rather than referring to 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. 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 a prerequisite 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.

4. 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 associate
with the external data source.
An 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 save your team’s time and effort. 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.

5. 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 the 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 they 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 is a dedicated Salesforce partner organization, headquartered in Dallas, Texas. Our
unrelenting focus on comprehending the unique needs of our clients coupled with our unrivaled
expertise of the Salesforce platform enables us to deliver the perfect solutions that create the best
value. Our unflinching commitment to quality and affordability has earned us a 100% Customer
Satisfaction (CSAT) score from all our customers.