Planning Ahead for a Salesforce Integration

salesforce-data-integration
salesforce-data-integration

As companies continue to leverage Salesforce for their business, they are likely going to come across requests from their internal customers to keep all of the business data in one place. By now most corporate employees are aware that web systems can be set up to talk to each other. We see it all over social media, and it has become a part of our daily lives: integration. So when your user comes to you and asks, “Does Salesforce integrate with our (put system name here) system?”, you can wholeheartedly say “Yes!”. The real questions won’t come from your users; instead, they will be to your users.

“How often do you want the data updated? Why do you need the data in the system? What reports are you going to run with this data? Who needs to…” and on and on.

The effort involved with a Salesforce data integration will likely come from the actual planning. Generally, database structures are very similar. The data will likely be more normalized than in Salesforce, but in the majority of Salesforce integrations, it is simply a mapping exercise from the backend database to Salesforce. So, where is the real effort?

There are many factors to take into consideration prior to a Salesforce integration, but the following three subjects are what I find drive straight to the core what truly needs to be integrated. This is rarely how the business will be looking at it.

salesforce-integration-storage
salesforce-integration-storage

Storage: How many records are we looking at storing in the system? Why do we have to store these records in the system? What is the business purpose of viewing these records within Salesforce? Do they simply need to be viewed in Salesforce or do they need to be reported on?

Data Update Frequency: How often are records updated in the source system? Will the update to Sales/Service/etc. help them to perform their duties more effectively? Are reports on this data run multiple times a day?

Directionality: What is the reason that data needs to be updated? What is the source of the data? Which system causes the update of the data? Do both systems require updates from each other? What is the status of the Web API in the secondary system?

Finally, the last subject that must be addressed in any Salesforce integration is whether to build or to buy. Salesforce has an open API, however, many systems do not. Salesforce is very flexible, and most business requirements (in my 10+ years experience) can be accommodated through the use of one of the APIs. This is not the case with all other systems. Many times the API for the secondary system needs to be changed or may need to be created altogether. This can become costly for both the changes to the Secondary system and the amount of coding you may have to create within Salesforce. In this case it may be much better in the short and long run to buy an ETL tool.

ETL-tool-Informatica
ETL-tool-Informatica

There are currently many ETL tools out there today. The one that I use when leveraging these tools is Informatica. This system will not only connect to most backend systems, but also assist in complicated business processes. The best system to choose will be the subject of another blog post because there are many other factors to consider in that decision.

To sum up, the more time spent planning for a Salesforce integration will reduce issues that could arise in the future as your business continues to grow. You should not second guess moving forward and starting the build, however, you should make sure that you understand the current state of things and where you want to leverage the integration in the future. It will prevent costly mistakes, including what platform to use in the Salesforce integration.

Blogcrm-manager-admin