There is plenty of information on the internet that talks about various integrations, tools, and integration patterns. In fact, there is so much information that even the most experienced integration architects and developers can get confused and lose track.
If you are looking for an overall summary about every possible integration pattern, this is probably the wrong article for you. But if you are an experienced Salesforce user/ Salesforce consultant/ Salesforce Solution Architect and/or Technical Architect and you are about to implement a new business process of a CPQ or a field service to one of your customers which contains integration, then you arrived at the right place.
Imagine that you are about to finish a workshop with the customer. While gathering all the information that is related to the general process, you begin to worry because the last day is dedicated to an integration topic. Though you heard about it before, and this term is not completely foreign to you, you still don’t feel comfortable enough to lead this conversation and ask the right questions. I am here to help with exactly such scenarios.
Please follow the next steps, and I promise that it will assist you greatly to determine the integrations, their scope, and the pattern.
The First Step: Identify possible integration points and analyze them with the customer. My personal favorite technique is to scratch the business process flow and to mark in the flow all the transactional and the data movement points. By “data movement,” I mean information which needs to reside within the system to support the process. For instance, in order to bill, you need information about Accounts (Customer bill-to), Locations (Customer ship-to), Contact, Product, Asset, etc. This information needs to reside in the platform. In order for it to happen, it needs either to be loaded through one of the data load tools, created within Salesforce through the UI, or integrated into the system. The “data movement” also supports transactional data such as Inventory adjustment or Order to move from Salesforce to an Accounting/Billing system. At the end of the analysis, we should roughly know which integrations we need to implement.
The Second Step: Determine what is the source of truth, also known as the “Master Data.” In more simple words, if there’s a discrepancy in the data, which source is above all the reside. Definition of the source of truth assists us in determining the direction of the integration. The rule of thumb is to avoid bi-directional integration, as it might create a confusion of which system triggers the event, which system is the master, and which is the slave (possibly overriding a newly created data). It can also create a recursive endless loop, as the 2 systems will continue to trigger each other endlessly. The bottom line, it’s a nest of worms. If you really need to go that route, do it very carefully and plan well ahead.
The Third Step: Try to find out about the volume–both daily and hourly. Check if there are high spikes of data flux at specific hours, as a very high volume may cause delays of data movement and might hit the Salesforce governor limits.
The Fourth Step: Ask how often the data is being updated. For instance, if a Pricebook is being updated once in a year, dataloader will be a great solution.
The Fifth Step: Use a “Real Time” integration or “Close to a Real Time” or “Batch” System that is being integrated to get a response. If the business is ok with it, Batch is the preferable option.
A Real Time with a response is the most complex option as it requires to build a LWC.
The Sixth Step: Define integration points and triggers for when the integration needs to be sent over. Consider the threshold conditions that will trigger the integration.
The Seventh Step: Determine whether or not to use a direct integration (Web Services) or a middleware. These are the advantages and the disadvantages of each approach:
The Eighth Step: Get dirty and delve in to find out about some technical aspects which affect the project scope, complexity, and of course, the budget:
With this information in mind, you now have a strong start and better understanding of how to approach the integration.
Principal Consultant & Technical Architect at Uptima