Integration Considerations for Every CRM Implementation

Salesforce Integration/Implementation

To get the most out of a Salesforce implementation, integrating it with backend systems is often necessary. Numerous tools are available to assist with the transfer of data between Salesforce and other systems, and they all have their pros and cons. Regardless of the tool, an integration plan must be in place to get the most out of any technology investment. Using the five questions a good reporter asks when investigating a story, we’ll examine some of the keys to building the right integration plan.

Why?

The first question to ask may seem obvious, but in certain organizations it can take a long time to answer: Why do the systems need to be integrated? Whether the need is to give sales reps access to order history, letting the service team see the status of an order, or to streamline a manual process, clearly stating the purpose of the integration helps define the scope of the integration. Sometimes the answer results in not transferring data between systems at all, but instead leads to finding a method for keeping the data in the native systems and displaying them in the other system (i.e. a mashup). For our purposes, we are going to assume the answer will require the movement of data between systems.

Where?

Where does the source data reside? Sometimes the answer to this question is harder than one might think. Maybe we’re lucky and everything needed sits in one database; but often the data is spread throughout an organization. Spreadsheets might be pulled together using multiple sources, and the end consumer of those spreadsheets may not fully understand where the data comes from. Maybe a data warehouse contains some of what is needed. Usually it’s a combination of these things, so further investigation is needed to isolate the true source of the data.

Where is the source data going? Locating the source data is important, but so is knowing where its new home is going to be. Will new tables/objects and fields need to be created in the destination system, or do fields already exist? Keeping in mind how the system should look once the integration is complete usually makes this question easier to answer. Think about the kind of reports that you’ll need, or how the user experience should be when interacting with the new data.

What?

The next question gets to the heart of the work: What data should be transferred? Identifying exactly which data elements to include in the integration usually requires subject matter experts in both systems. Does transactional detail need to be moved into Salesforce, or can it be summarized to save on space? What kind of reporting is desired? Are the fields included in the integration providing the detail needed to produce the right reports? Is there a unique identifier, such as an account ID, in each system that can be used to easily tie a record in one system to a corresponding record in the other system? Is this a one-way integration, or will data need to move in both directions? Which system will be the “source of truth” if there are conflicting values? Building a data map of fields in the source system to the destination system is critical in this step.

How?

How is the data going to be moved between systems? This question leads to selecting the right tools for transferring the data. Selecting an integration tool is beyond the scope of this article, but an important aspect to consider is the skillset an organization has internally, and the appetite for learning a new tool. If an organization is strong in SQL Server, for example, looking at tools that work well with SSIS may be the right answer. Can data be exported from the source system into CSV files? If so, then perhaps DataLoader.io is a better solution. The key is to find a tool that provides the features needed and can be managed well internally.

When?

How often does the data need to be transferred? The frequency with which the data moves between systems can have a large impact on the integration solution. Can the transfer happen periodically (twice a day, once a week), or must it be real-time? Can the transfer happen in batch, or must it happen when an event is triggered (i.e. when a record is changed)? Knowing how often the data must be refreshed helps scope the integration plan and also helps when choosing the tool to use.

Who?

The final question ties into the “how” question: Who will be responsible for maintaining the integration? Once again, the skillsets available to an organization impacts the answer to this question. Ideally the person has a solid knowledge of both systems, as well as the technical prowess to make changes as needed.

Keep these questions in mind when building your own integration plan. Finding the answers can be time-consuming, but well worth the effort for a successful implementation. For a more detailed integration document, and for some best practices, see this excellent white paper provided by Salesforce: https://resources.docs.salesforce.com/sfdc/pdf/integration_patterns_and_practices.pdf

Written by Eric Gronholz, Demand Chain, Senior CRM Consultant

Eric Gronholz has over fifteen years of experience as a leader in defining and improving CRM practices for a variety of industries, and nearly twenty years in the IT field. As a practice lead at Demand Chain, Eric wears many hats including: CRM advisor, project manager, technical and business analyst leader, and trainer.