Salesforce is a very powerful platform that includes features that enhance customer experiences and streamline workflows.
However, you can do even better by integrating Salesforce with external systems and apps.
Salesforce is equipped with frameworks that can be used to integrate with external systems, allowing you to supplement and customize baseline functionality with the capabilities of third-party software.
In this article, we’ll be looking at some entry-level concepts around Salesforce integration solutions, including:
- What Salesforce integration actually is?
- Why is it useful?
- What types of Salesforce integration exist?
- What kinds of capabilities does Salesforce integration provide?
- What does a typical Salesforce integration project look like?
Let’s get into it!
Integration just means putting multiple things together in a cohesive way – that is, we say that two systems are “integrated” if they communicate with each other effectively and usefully.
Salesforce integration, as you might expect from the definition above, is the process of integrating other systems with the Salesforce platform. This can be done with a wide range of external systems and tools.
Salesforce integration services are important for a variety of reasons:
By making sure all of your systems can “talk” to one another, you also make sure that data is consistent across the systems.
No more updates of customer information in a consumer app that aren’t cohesively copied into your central database!
Salesforce integration means you can avoid replication of data, which will save you money, storage space, and time. Plus, you don’t have to painstakingly transfer useful information between systems by hand.
Additionally, you are able to reduce swivel chair by completing tasks such as document signing, automated emails, appointment booking, email verification, and more, all without leaving your Salesforce environment.
Making sure that your systems are talking to each other as much as possible will necessarily improve customer experience, as they’ll receive a consistent picture of the company through all their interactions.
On top of this, you’ll receive a better and more comprehensive picture of the customer than you would if you relied on many different disconnected systems to store customer data.
An API, or Application Programming Interface, is a way for two applications or platforms to talk to each other.
For example, there is an API involved in just about every app on your phone that collects data from the internet – providing a bridge so that your app can request data in a language that the internet understands.
The internet can then send that data back in a language the app understands.
You can have systems talk to each other in two key ways, both of which are good for different purposes.
Synchronous integration processes are processes that require communication to occur before continuing to run the application.
For example, think about loading a web page on your browser. You can’t interact with the web page before it has loaded. In this case, the integration is between your computer and the server on which the website is hosted.
Asynchronous integration processes don’t need to finish before one of your integrated components continues running. A request is submitted, and then you can continue using the application without a reply.
An example of this would be updating a linked database after making an edit to a separate system – for instance, updating estimated resource allocation after adding a new customer or group of customers to Salesforce.
While this probably shouldn’t sit around waiting to happen for ages, it’s not necessarily a bad thing if it takes an hour or two.
Salesforce Integration Architectures
There are three key kinds of architecture for seamless integration:
Point-to-point architecture creates connections directly between Salesforce and different external applications.
Think about it like a small airline. A plane flies a very specific route, from Airport A to Airport B, and back again. It could also fly from A to C, or A to D. Each trip is direct and discrete.
This is a good option for small systems, where you don’t have too many integrations to deal with and don’t plan on expanding any time soon.
However, if you want to go bigger, you’ll find that adding individual connections can become both tedious and difficult as you increase the number of integrated systems.
A hub-and-spoke model sends all Salesforce connections to one external tool to process them, which in turn connects to all the external infrastructure you have.
The best way to think about this one is a public transport system, like a bus or train network.
Each bus/train starts at one point, travels to a central interchange (typically somewhere in the middle of town), and then people can switch buses/trains to go to the next place they need to go to.
This is great for adding new systems, as you need only connect them to the hub and they will be connected to all the other systems you have!
However, if your hub goes down, that does mean none of your systems can talk to each other – which might be a concern if you rely on 24/7 uptime.
ESB architecture is similar to hub-and-spoke but avoids some of the issues. In ESB, each integrated application reads messages from a central “messaging backbone” (the bus), decoding and processing it themselves if it is relevant to them.
This means that we don’t have as much of a bottleneck as in the hub-and-spoke system, as well as further ease in removing or adding new integrated systems.
In this case, you can think about the system as a luggage conveyor belt at an airport.
Everybody standing around is an integrated system looking for a very specific kind of “message” (ie, suitcase) which they will then do something with (take with them).
No processing occurs on the conveyor belt (the bus) – it is all done by the systems integrated with the ESB.
Salesforce can integrate with a wide variety of software types.
In general, RESTful APIs are very flexible in terms of design but may be more limited in possible actions than other API types.
However, it does add some additional features and a better ability to update and request salesforce data such as leads, passwords, and so on.
Bulk API is an API built for Salesforce based on RESTful architecture principles that is specifically designed to handle the bulk transfer of information. It’s best designed for asynchronous processes, as bulk updates can take some time to complete.
Streaming API is best for instances where a client requires a lot of information from the host, and quite frequently.
It minimizes load and maximizes efficiency by “pushing” data to the client rather than waiting for the client to make a request.
Outbound message sends information to an external server whenever a change in a particular Salesforce field occurs.
This can be something like updating a customer record in an external database.
However, it should be noted that while Salesforce continues to support outbound messages as a framework, it is no longer actively developing with it.
Web service callouts (or just callouts) are where you make a request from Salesforce to an external server, typically one on the web.
This can be for multiple reasons, but chief among them might be using an existing large database (for address verification, for example).
Salesforce Connect is a way to gather data from an external server without necessarily having to copy it into your Salesforce system.
This is particularly good when dealing with data that must be “fresh” at all times, but you don’t want to take up space in your Salesforce system.
Heroku Connect is a bridge between the Heroku software and your Salesforce system, allowing you to create applications that tie directly to your Salesforce records.
Point-to-point, hub-and-spoke, ESB – which type of integration suits you best?
Think about the number of supplementary tools you’ll be using with Salesforce, as well as how independent you want the systems to be of each other.
Make sure that your data is stored in an appropriate format to be passed through your integration network.
You’ll also want to check that you have the appropriate data protections on each component of your integrated system.
Make sure you understand which Salesforce data is being sent where. If an application requests a customer record – which is held in a section of Salesforce – where should that data be stored when it is returned to the application?
This is the nuts and bolts of the process. Configuring the integration can be as simple as using Salesforce’s own tools or as complicated as writing custom code to fill the gap between Salesforce’s system and your target to integrate.
Before going live, make sure that your integration systems are working as intended by trying some test inputs.
It’s a good idea to try unexpected as well as expected inputs to ensure that you are able to deal with all possible inputs.
Once you’ve hit the Go Live button, make sure that things don’t unexpectedly stall or go wrong!
Keep an eye on the performance of your integrated system and make sure you’re ready to step in and improve or fix things if need be.
Salesforce is a very powerful tool with a lot of different applications. By integrating your other systems and using Salesforce apps, you can increase productivity – providing a more cohesive user experience and generally streamlining your processes.
To do this, you can use a variety of tools to help applications interface with each other and construct an interfacing architecture appropriate to your particular use case!