Integrating with Salesforce: 5 Questions to Consider & Ask Your Consultant Before Getting Started

The more engagements I work on, the more it seems that integrating Salesforce with other systems is becoming a bigger topic. At the very least, the word “integration” is one of the most popular terms to be used in conversation–whether or not the definition and implications are understood is another question. Needless to say, integrations, whether they be bi-directional, one direction, or manual, makes sense – if data that can pass from Salesforce to another system and back again, it helps increase efficiency and reduce duplicate data entry. The great news is that there are increasingly more apps in the Salesforce AppExchange to help establish these integrations, and for other solutions, there are plenty of ways for developers to work their magic to get it to work.

Of course, system integrations can bring their share of headaches which are often not fully considered when making the decision to pursue an integration. At the end of the day, you are trying to get two different systems built by two different companies to work in sync with each other.

I liken this to my time working in Costa Rica. While I am fluent in Spanish and have spent many years living abroad, when I moved to Costa Rica I was not familiar with the local dialect or their customs in the workplace. Could I communicate and interact with my Tico colleagues? Of course. However, was a word lost in translation from time to time? Definitely! Did I make mistakes that clashed with the local culture? Probably more than I realized.

Integration is all about figuring out how two systems speak and interact with each other and, in most cases, a great thing to pursue. Before starting, here are some questions executives and project managers should consider before initiating a new integration project.

1. What information needs to be moved between the systems and how often?

Without a doubt, your Salesforce instance has a lot of data in it, and likewise, so does the system with which you want to integrate. It is important to take the time to sit down and map out exactly what needs to be moved over. Remember, sometimes less can be more.

Taking a simplified version, let’s imagine you’re looking to integrate Opportunities in Salesforce with a finance system. The Opportunity object has about 20 standard fields, never mind any custom fields that have been added. Do you need all 20 to sync across, or are there 5 or 6 key fields that are required? More importantly, once you identify those fields, do they have a “home” in the other system?

Once you identify the data that needs to be synced, the subsequent questions are which directions does the data need to sync and how often? I recommend creating a simple spreadsheet to help track all of this. It would have the following columns:

Name of Field in Salesforce
Name of Field in Other System
Type of Field (Text, Date, Currency, etc)
Description of Field -Direction of Sync (Salesforce to Other System, Other System to Salesforce, Bi-directional)
Frequency (Every 2 hours, once a day, etc)

If you go through this simple exercise at the start of the project, it will not only give you a basic checklist, but also help you to prepare a strategic roadmap of the requirements for the integration.

2. Who is the expert on the non-Salesforce product?

While I am always flattered when a client thinks I am an expert on all systems, at the end of the day my focus is Salesforce. While I have some knowledge of a lot of the other products that are commonly integrated, and while I can also conduct some research, most likely you will have another resource, either internally or externally, who knows the system much better.

The sooner you identify that resource and get them in touch with your Salesforce consultant, the smoother the process will be. It will be important that both parties create a project plan together, and it helps assure that one is not making assumptions of the other.

3. What are the benefits to integration? Will the automation increase efficiency?

Recently, I worked on an integration between Salesforce and our financial system for OpFocus. For reasons not worth going into, the project took much longer than expected. I remember being excited when it was finally live and invoices created in Salesforce passed seamlessly into the financial system. When our finance manager saw it, her response was “that is great, but you only saved me about 15 minutes of work a week.” After you have invested time and money into creating this integration, this is not the response you want to hear!

Before signing off on an integration project, make sure you have a clear understanding of where the efficiencies lie and how much of an improvement any automation will have on the daily operations of the departments impacted. Also, make sure each department understands how the changes impact the whole team. In my above example, the integration may not have helped finance tremendously; however, it had a much bigger impact on other departments who had visibility into payments that they never had before.

4. Is your company prepared for ongoing investment as upgrades are rolled out?

Too often, an integration completes just in time for one of the systems to upgrade, causing a whole new round of bugs. As you know, Salesforce releases upgrades three times a year, and many other products out there are equally aggressive with upgrades.

Continuing with the financial system integration example at OpFocus, suddenly right before Christmas I started receiving numerous integration error messages. I worked with the vendor and it turned out the financial system released an upgrade that impacted the integration, not only for OpFocus, but also for everyone else using the tool. Fortunately, the issue was resolved in under an hour and the cost was minimal; however, if an upgrade breaks any code created by a developer, the cost could be much higher.

5. Who is available to help troubleshoot when something goes wrong?

I am working on one project that has a tremendously complicated integration process. Every day, there are hundreds of error messages generated about issues with the integrations. In some cases, the problem fixes itself the next time a job runs; in other cases, it requires human intervention and research.

The point is, before you finish with an integration project, you must have a clear idea of the ongoing customer support that is available to you by the consultants or the product offering the solution. If a failed integration causes a show-stopper for your company or for a department and it requires an external resource to solve, then you want to make sure you have a service level agreement in place that will guarantee the issue is addressed.

Conclusion

There are tremendous benefits to integrating your technology systems and it can be very rewarding to see the efficiencies these integrations bring to your organization. By asking yourself, or your consultant, these five questions before starting an integration engagement, it will help to ensure a smoother development process and a much more positive launch.

At OpFocus, one of our most important jobs is to be your trusted advisor. As we work with you on integration solutions, we will be asking these questions along the way. Sometimes we may even ask “are the gains worth the effort?” This is simply because we want to help you improve and enhance your business processes while ensuring nothing is lost in translation.