The age of the application programming interface (API) is upon us, and the ability to connect disparate digital platforms to your Salesforce customer relationship management (CRM) system is easier than ever.
Connecting multiple systems together to consolidate or leverage data in your Salesforce CRM is achieved through the use of integration with a Salesforce API. Integration creates a pathway for data to travel between software systems, allowing information in one to become available to another.
Unifying your various enterprise software into one view can allow your organization to service its customers and understand its business like never before.
Whether it’s integrating new reporting, connecting an enterprise resource planning system (ERP) to client records, setting up a new Salesforce product — or allowing sales executives insight into the projects they’ve sold their clients- integrating multiple software into your Salesforce CRM can save your company time and money while providing new, synergistic insights in near-real-time.
Integrating new software with Salesforce isn’t always straightforward, however. From common software such as DocuSign to proprietary products that require data warehousing and middleware such as MuleSoft, Salesforce integrations can still present challenges if not well planned and carefully executed.
Here are 10 common mistakes and tips on how to avoid them to ensure that your Salesforce integration is a success.
An undefined project scope will kill an integration project faster than any other issue on this list because lacking a clear understanding of what needs to be done by whom is guaranteed to harm your integration before it even begins.
It is vital to clearly establish the goal of your integration project, the extent of its reach, its data maps, its product owners, its stakeholders and its maintenance schedule before any work begins. Project uncertainty and too-many-cooks can hinder or obscure the project scope of your integration and it is critical that you set realistic expectations and timelines upfront. Don’t be afraid to defer work to a phase 2 if scope creep begins to happen — and seriously consider seeking an executive sponsor to champion your integration project and keep it on track.
Furthermore, don’t neglect to involve infrastructure and security personnel in your Salesforce project scope if your company has special data security or compliance divisions. Often, larger companies have strict requirements governing the methods by which systems are allowed to communicate, so be sure to get a blessing from any security review boards before you begin your project. Otherwise, you may be forced to stop the integration halfway because it violates compliance.
It is said that creating a duplicate record costs a company $1, that cleaning it costs $10 and that doing nothing costs $100. The costs felt by housing bad legacy data will never be more apparent than when initiating an integration.
Not only can bad data cause data type mismatches or format inconsistencies during your integration with Salesforce, but connecting bad data to otherwise clean data will pollute your data quality and diminish the overall dependability and accuracy of your system. Bad data can hobble your Salesforce integration or render the integration completely irrelevant because the information it provides isn’t actually accurate or actionable.
The solution? Plan to invest in cleaning up legacy data in systems slated to be integrated with Salesforce before you begin. Don’t be afraid to put some of your legacy data into cold storage, either. An abundance of shoddy free-text or questionable data doesn’t turn it into good data.
Many common enterprise programs likely have saved you the trouble of creating your own API by providing point-and-click connectors that will do the work for you with minimal configuration. You can save yourself time, development money and heartache by leveraging the solutions of experts on your specific software. While turnkey connectors aren’t advisable in every integration, they are becoming more widely available.
Browse existing solutions on the Salesforce App Exchange before creating your own custom API. Only consider a custom API if the established mappings and data calls in existing connectors don’t fit an extremely specific need, such as privacy concerns, highly customized architecture or compliance requirements. Alternatively, consider turnkey integration solutions such as Zapier, which can facilitate mapping with declarative tools to avoid common problems integrating with the Salesforce API
If you are dealing with a multiple-software environment with client records, you must determine which system integrated with Salesforce is considered the master system. This is critical in establishing which values are “correct” in the event of an outage, user errors or batch processing failures. Your master system of record might not be Salesforce or the software you plan on integrating. You may even need to consider a data lake, data warehouse or backup systems in the event of errors during bidirectional sync.
A clear master record plan will allow you to maintain good data hygiene that prevents data debt. You can also leverage other Salesforce Tools (such as Validation Rules or Process Builder) to maintain data cleanliness, remove record duplicates and prevent Salesforce problems caused by bad data. Many of these solutions have the potential to create audit trails to determine the cause of process or integration failures.
Planning your data mapping might seem like an obvious element of integration planning and execution, but the primitive data types of the Salesforce System Architecture have a few quirks that can create nasty surprises and Salesforce errors during your integration.
Data Mapping is the act of matching a data type in one system to the data type in another system, to ensure that your data can move freely between your integrated systems. Carefully mapping and potentially transforming your data types will prevent errors with the Salesforce API.
Formatting certain data types, such as date and date/time, can often cause unexpected problems, so be sure to plan for any potential inconsistencies between external data types and Salesforce data types. If the systems you are trying to integrate with Salesforce can’t accommodate Salesforce data types, you may require middleware or custom code to transform them.
Additionally, data categories such as financial data, health data, or Personally Identifiable Information can be legally required to be encrypted or handled in a specific fashion. If you are dealing with multiple stakeholders or owners of software products, you may not be aware of encryption requirements, and you need to have an open discussion about which data requires special attention. Encryption might exist in one system, but may be forgotten in another, so plan to handle any special keys or encryption accommodations.
Not all integrations require a simple object access protocol (SOAP) API and a few good data maps before you can call it a day.
You most likely will require middleware to help your systems communicate with each other cleanly if you have:
Middleware accommodates multidirectional solutions effectively and securely, allowing you to create one-to-many integrations with less complexity. Middleware also can act as a buffer between integrations, protecting the master system and allowing it to otherwise run its batch jobs if the contributing system fails.
Furthermore, maintaining system updates, troubleshooting API issues and monitoring the overall performance of all your integrations are much easier if housed in middleware, as it makes for fewer systems to monitor.
The canonical Salesforce middleware is MuleSoft, but there are several other middleware options built to work with Salesforce.
Integration security holes can be a prime target for malevolent external forces if you use a dodgy connector, fail to maintain encryption certificates or aren’t following proper Salesforce security techniques when writing custom code. In addition to ensuring that protected data types are properly encrypted, be certain to investigate any inadvertent data exposure to end users in your master system or in Salesforce.
If your integration is pushing data from Salesforce to another software, be mindful of the security sensitivity of your Salesforce data within another system. As mentioned, middleware can be a useful tool to mitigate or support firewalls to avoid potential leaks or cyberattacks, but don’t neglect basic security features in Salesforce for internal actors, such as field-level security.
Several elements in integration can lend themselves to system exposure or weakness. It is important to identify potential risks and build security contingency plans before beginning your integration projects. Create a potential risk map and conduct audits of your integrations even after they are implemented.
Technically, all Salesforce orgs are part of the same Salesforce org, thanks to multitenant architecture. Consequently, Salesforce must protect the safety of the overall org by instituting limits regarding the methods by which data can be called and stored. Failing to consider how often your integration requires API calls to Salesforce can crash your entire integration and cause critical jobs within Salesforce and your other systems to fail.
Account for the fact that Salesforce integrations aren’t exactly performed in real-time, although they may seem that way. Salesforce processes the transference of data via API in batch jobs, which run in parcels and can sometimes experience slight runtime delays from their intended schedule. Depending on the quality of your processing architecture, if an error is experienced during part of your batch job, the entire batch job may fail.
If you are pushing sizable files from an external system into Salesforce (JPEGs and PDFs are frequent culprits of this), carefully layout your file storage and compression plan, as it is easy to exceed your contractual storage in no time at all. Consider housing large file types with other methods or calculate how much storage you may require overtime.
If you’re planning a custom integration or an integration on a complex system, it’s almost always a good idea to test the integration in a nonproduction environment. It may even be the time to call your Salesforce account executive and cut a check for a full or partial sandbox if the scope of the integration or the complexity of your custom Salesforce architecture requires full data quality assurance testing.
Additionally, don’t neglect to run full user acceptance testing (UAT) on your integration, as you will want to ensure that user performance or established reporting aren’t impeded by any of the fields or backend work your new integration might require. You also want to ensure that incoming data from other systems isn’t accidentally exposed to people within your organization who aren’t supposed to see it.
Perhaps the most forgotten integration “gotcha” in the Salesforce integration landscape, Salesforce products that aren’t Sales and Service Cloud operations often require integration planning and execution during their implementation.
Examples of Salesforce products that aren’t immediately turnkey are the marketing services, namely Marketing Cloud and Pardot. While Salesforce does provide implementation and integration guides, introducing these new clouds to your org does require some legwork on the part of the customer (or the customer’s implementation partner) to make sure the new clouds are mapping to Sales and Service Cloud properly.
If you’ve strayed away from Salesforce architecture best practices, such as using custom objects that should actually be standard ones, writing redundant code in the form of Apex triggers and classes or creating duplicate fields instead of leveraging out-of-the-box functionality, you may find that the Salesforce product you just bought won’t work as it should.
Data mismatches frequently happen in the marketing products listed above, often creating buyer’s remorse and a need to significantly overhaul the existing architecture of a Sales and Service Cloud build to get the products to work as specified. You also may need to accommodate “hard” data resets or other manual pushes to get fields to remap in these sister systems, so do your integration research upfront before purchasing another Salesforce product
Salesforce integrations can be an excellent way to reduce duplicate work and centralize enterprise data in a consistent manner, but it is very easy to make mistakes during your integration. The possibilities for Salesforce integrations are infinite, and the vast array of third-party Salesforce connectors and custom code options provide you affordable and flexible options to tailor your integration to your organization’s needs.
Combining multiple enterprise systems allows for better collaboration and insight into system processes that ultimately create a better experience for your employees and your end users. If you plan your integration thoroughly and efficiently while rigorously reviewing potential arenas for errors, your Salesforce Integration is likely to be a great success.