The vast ecosystem of 3rd-party integrations 1 is one of the big reasons so many nonprofits use Salesforce. There are integrations for everything from broadcast email and SMS messaging to online donations and advocacy. A good integration is incredibly valuable: it will put data at your fingertips, save you time, and help you make better decisions about how you engage your audiences.
But not all Salesforce integrations are created equal. Quality varies a lot. And a bad integration can cause huge headaches, sucking up time on troubleshooting and putting your data at risk.
It’s not wise to adopt a new system just because it has a Salesforce integration. You need to know if it’s a good integration. To help you separate the wheat from the chaff, here are 5 essential qualities that we look for in an integration.
Don’t miss part 2: How to evaluate an integration
Reliable. Let’s start with the basics. Reliability means the integration does what it’s supposed to do, when it’s supposed to do it, every time. Obvious, right? But you’d be surprised how many integrations don’t meet that standard. It’s a simple concept, but there’s more to it than meets the eye.
Salesforce is so extensible that creating robust integrations is not easy. Developers have to reconcile different data models, play well with other AppExchange apps you may have installed, and handle the inconsistencies of real-world data. The app has to do all of that while observing API call limits, storage limits, etc. that vary from client to client. Oh, and have we mentioned that even the most bombproof cloud services sometimes go down?
A sync may work in the vendor’s test environment, but not in your Salesforce instance. Or it may work most of the time, until it has to deal with that one unusual record or that high-volume day (like your year-end fundraising campaign). The best integrations anticipate differences in Salesforce systems, and are nimble enough to deal with them, either automatically or through configuration (see below).
Reliability also means recovering gracefully from problems. What happens if Salesforce can’t connect with the outside app, or the sync hits an error? The best integrations have a queueing system that can retry syncs that fail the first time. Some have “self-healing” mechanisms, so missing data won’t cause a cascade of problems. Without features like this, you will run into problems eventually, and end up with missing or messed up data.
While building a reliable integration isn’t easy, having one is essential. There’s almost nothing worse than a sync you have to babysit, or clean up after. You can end up with something that causes more problems than it solves. It’s worth the effort to find the most robust solution you can.
Transparent. Reliability doesn’t help that much if it’s not clear what the integration is doing. We’ve seen integrations that sync something every night, and don’t throw errors, but constantly surprise us when we see what’s been synced. (And, even scarier, what hasn’t been synced.)
Transparency is about predictability. Is it clear when and how data will flow between the two platforms? Does it happen on a schedule, or in real-time? Is it checking for duplicate records, and if so, how? When these things aren’t clear, it is extremely difficult to test and troubleshoot problems. You don’t know what’s a bug vs. expected behavior. And reverse engineering a complicated integration to figure out why something didn’t sync is a rabbit hole you do NOT want to go down. (Trust us, we’ve been there.)
Ideally, the app’s written documentation will cover all of this in detail. Or the app may have helpful on-screen instructions and tool tips. Sometimes the vendor’s tech support can fill you in. But the main point is: make sure you get clarity before you adopt.
Configurable. Most Salesforce-integrated apps have settings that allow an admin to customize how it works. But how much you can control varies a lot. Some have just a few general settings while others allow you (or require you) to map every field that will be synced.
Unlike reliability and transparency, where more is always better, here it’s a little more complicated. You need enough control to make it work with your system. And you often want to be able to tweak where the data goes. So some configurability is needed. But too much can also be a problem.
We’ve seen integrations that have so many obscure-sounding settings that configuring them is like climbing into the cockpit of an airplane. Have we mentioned that transparency is important? If it’s not totally clear what a setting does, it doesn’t help you. Other integrations are so flexible that it’s easy to get it wrong and set it up so that it mangles your data. You don’t want to have to spend a bunch of time on trial-and-error when you’re setting it up.
The best integration is configurable enough to enable 90% of its adopters to do what they want with their data, while not complicating things with settings that only 5% will need. Their settings are easy to understand and to change. And they protect you from making big mistakes that could damage your data.
Well-Supported. No matter how reliable, transparent, and configurable an integration is, there are going to be times when something goes wrong, or you have technical questions. At those times, you need to be able to rely on the vendor’s technical support. Like everything else, the quality of that support varies quite a bit. Some vendors know all the ins and outs of the integration and can help you solve any problem, and even strategize about the best way to configure it for you needs. At the other end of the spectrum, other vendors don’t really try to provide tech support for the Salesforce integration, and have support reps that say “I don’t know anything about Salesforce.”
Keep in mind that in many cases, companies hire outside developers to build their Salesforce integration, because they don’t have expertise in-house. That’s not necessarily a bad thing. We’ve seen great integrations that were built for hire. But you don’t want an integration that was built and then handed off to a vendor that doesn’t know much about it. Not only does this mean you can’t get the support you need, but it may be a warning sign that the integration won’t get timely improvements and bug fixes.
So just because Acme Marketing Automation generally has great support doesn’t necessarily mean they know enough about the Salesforce integration to be helpful — or that they have a good system in place for getting help from the developers. You should be looking for apps that have great support throughout, including for the Salesforce integration.
Plays Well With NPSP. Most of our clients use Salesforce.org’s Nonprofit Starter Pack. NPSP is a powerful suite of customizations for nonprofits, and it does a LOT of stuff behind the scenes to make your life easier and keep your data in good shape. But not all Salesforce-integrated apps are used only by nonprofits. The builders of apps with broader scopes often aren’t familiar with NPSP. And even those that are NPO-focused aren’t as savvy about the NPSP as they should be.
Why does this matter? NPSP has its own data model, especially around Accounts and Opportunities. If an app isn’t built to work with the NPSP it may not save data in (or pull it from) the right place. And there is a lot of code running every time you create or edit a Contact, Account, or Donation. Apps that play well with the NPSP will take that into account — both in understanding how NPSP changes data and in ensuring it stays within Salesforce’s built-in limits on transactions.
In the coming weeks, we’ll follow up with tips on how to evaluate that Salesforce integration. In the meantime, check out Bigger Boat’s questions to ask when choosing a core Salesforce app for your organization.
Notes
1. In this article we’re talking about off-the-shelf integrations between Salesforce and external systems. This boils down to: is there a non-SF server involved? Click & Pledge is a good example. While it’s mostly used in concert with Salesforce, and its integration includes an AppExchange package that contains a lot of Apex code and a complex Salesforce data model, the donations are processed on Click & Pledge’s servers, and those servers send the donation data to Salesforce via the API. Volunteers for Salesforce is a good example of the kind of integration we’re not discussing in this post. It is a fully native app that runs entirely within Salesforce, so there is no API link with a non-SF server. We’re also not discussing custom-built integrations. (We’ll save that for another blog post.)