Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
The decision on the table is who carries the responsibility when data stops flowing between Salesforce and the rest of your landscape. Integrations are usually the last part of a programme to be tested under real load. They are also the part that is hardest to change once orders, customers and stock depend on them.
Integration is where accountability usually breaks
Most integration problems appear at the seam between two suppliers. The Salesforce partner says the message left correctly, the ERP team says it never arrived, and the middleware vendor points at both. Each party is right about its own piece, and your order is still stuck. The fix is contractual as much as technical: one party owns the connection from end to end and answers for it.
That is how we set up our projects. FORWARD acts as one point of contact and one accountable party, including for the integration between every Salesforce product involved. It is also the first question worth asking when choosing a Salesforce consultant: who picks up the phone when two systems disagree?
The integration pattern decides what you can change later
The right integration pattern depends on how many systems exchange data and how often those systems change. With two or three systems and stable interfaces, direct connections through each system's application programming interface (API) are cheaper to build and easy to follow. With many systems, or several consumers of the same data, an integration layer such as MuleSoft keeps each connection from breaking the others.
Both routes are valid. The light case needs little more than well documented APIs and monitoring. The heavy case needs middleware, an integration team and version control on every interface. We don't sell MuleSoft when a client doesn't need it, because a middleware licence without enough connections behind it is cost without return.
This choice is hard to reverse. Once dozens of processes depend on a pattern, moving away from it means retesting every one of them.
What the integration work actually contains
The build itself is the smaller part of integration work. The larger part is agreeing which system is the source of truth for each piece of data: customers, prices, stock and orders. When two systems both think they own the customer address, you get duplicates and overwritten records, and no amount of code fixes that.
Error handling is the other hidden workload. Every connection needs a rule for what happens when a message fails, who gets alerted and how the record is replayed. Data migration belongs here too, because the first load of historical data tests every mapping decision at once.
