Salesforce Integrations

• Salesforce integrations, what are they?
• What kinds of problems can they introduce to your Salesforce database?
• What can you do about them?

That’s what we’re covering in Unit 4 of our six part series on how to clean your Salesforce org

In this unit, I’m going to explain how to identify and review all of our existing Salesforce integrations in order to remove the mysteries of new records appearing unexpectedly, or existing records getting overwritten.

Let’s face it, if you currently have either of these scenarios going on in your Salesforce org, your users are likely really frustrated while also losing all confidence in the database.

In the end, these issues can typically be resolved with a few simple steps.

In case you missed the prior installments of the series

• In Part 1, we focused on understanding your business processes »
• In Part 2, we focused on understanding your existing Salesforce users ».
• In Part 3, we focused on your database architecture »

In this unit, we’re going to focus on your Salesforce Integrations and third party apps that are either feeding new records into Salesforce, or updating existing records into Salesforce.

By the way, if you haven’t done so already, make sure to download the PDF that accompanies this unit, as I believe that you will find it incredibly handy to follow up with some of the items in this article.

For those of you who don’t know me, my name is David Giller. I’m a Salesforce MVP, consultant, and trainer.

You’re Already Familiar with Integrations on Your Phone

Now just to put this scenario into a little bit of context, I’m sure you’ve experienced the following situation on your phone:

You open up an app, let’s say LinkedIn, Facebook, Twitter, or Instagram. When you’re looking in the app, there’s a nifty button prompting you to sync your contacts from your phone into that other app. You press that button, and the next thing you know, you just sent a Facebook request to your accountant, your babysitter, and maybe even your spouse’s college roommate.

Although the idea of sending a connection request to those people makes you cringe, that’s precisely what you asked the app to do by pressing on that button.

All too often, when setting up Salesforce for any organization, team members ask to have their contacts from Outlook or Gmail synced with Salesforce.

• Really?
• Is that really what you want?

You know, all of those non-work related contacts that you have in Outlook…are they flagged in some way in order to indicate that they are personal contacts versus customers and prospects that are also in Outlook?

That’s just one example of how a Salesforce integration can quickly go horribly wrong just by not taking into account the details associated with the integration functionality.

Let’s face it, the tool is doing exactly what it’s supposed to do.

Syncing contacts between the two systems means that the integration will pull contacts from one system and feed it into the other system. If you want to specify which contacts get synced, and whether or not the sync is one way, or two-way, or who has permission to sync contacts, then each of these configurations needs to be carefully reviewed and configured accordingly to meet your business requirements.

What is an integration?

By definition, integrations are data connections between two or more systems.

Within a Salesforce context, one of these systems is Salesforce, and the other system can be any other type of web-based tool or database.

Some of the common integrations seen with Salesforce

• Web forms:
  • Contact us forms
  • Download a white paper
  • Submit a customer support ticket or
  • Newsletter signup form
• Outlook or Google Integrations:
  • Contact sync
  • Calendar sync
  • Tasks sync
• AppExchange apps – connecting Salesforce to any other web based tool
• DIY Integration Tools:
  • Zapier
  • Workato
• Financial System Integrations
• ERP Integrations
• Custom APIs – Many organizations, particularly large enterprise size organizations before ever using Salesforce, they have some other type of homegrown custom system. Very often, they build a custom API in order to connect that other system into Salesforce.

Step 1: Identify Existing Salesforce Integrations

• Installed Packages – The first place that you’re going to look is in setup under Installed Packages. This is where you will quickly which other third party apps, any apps, for example, you might have downloaded from the AppExchange.
• Integrations configured externally – You can have an integration that’s not necessarily represented as an installed app. Aside from looking at the installed apps, my recommendation is that you ask around to other in house Salesforce admins, developers, or CRM leaders to ask about other integrations that they are aware of between other external systems and Salesforce.
• Look for Integration Users – Another quick, easy tip that you can look for is look at your existing active users and look for any indication that some of them are integration users.
• “CSI Method” – The last way you can identify some integrations that you might have in Salesforce is when you come across some mystery records that no one knows where on earth it came from or how it got updated. Simply look at the “Last Modified By” or “Created By” details on those particular records.

Step 2: Ask Questions About The Existing Integrations

Now once you’ve identified which integrations you already have within your Salesforce org, we need to start asking some difficult questions including:

• Why do we have this integration?
• How is it currently configured? Every time a new record gets created in the external system, does it automatically just create a brand new record in our Salesforce org without even checking to see if that record already exists?
• What happens if the information that’s submitted through the external system is less accurate, or different than the information that we already have for that same person or organization in Salesforce?
• Is the existing configuration precisely what we want and what we need today within our organization?

Step 3: Identify Modifications Needed to Existing Integrations

The next step would be to identify what modifications are needed to the integrations already in place.

For example:

• Should all records get blindly created?
• Should only some records get created?
• Should the system be looking for existing Salesforce records that might be either related to this new record that’s getting pushed into Salesforce, or perhaps duplicated?
• When a matching related record, let’s say, the same company, but a new person for that company is being pushed in from the external system, what should the integration do?
• Do you want to block the new record from getting created?
• Do you want to create the new record?
• Do you want to perhaps alert someone within your organization that the new record is trying to get pushed in from this external system, and perhaps it needs to be reviewed before others can actually see it?

Step 4: Modify Existing Integration Configurations

We need to implement the modifications that we’ve identified, in order to ensure that they match the current business requirements.

We certainly need to test the configuration modifications that we’ve just implemented before deploying them.

Step 5: Deploy Modified Integrations

The last step is to deploy the modified configuration. This is where you “go live” with the new changes, and communicate these changes to all Salesforce users so that they are aware of the enhanced configuration that you’ve just implemented.

Make sure to download the PDF handout that accompanies this section as it includes many valuable links and helpful resources to help you learn more about the topics covered in this unit.

I am looking forward to seeing you in the next unit »