Essential 5, Part 2: Evaluating Salesforce Integrations for Nonprofits

In a previous post, we talked about the qualities we look for in a good Salesforce integration: reliability, transparency, configurability, well-supported, and playing well with NPSP.

questionBut evaluating those qualities can be difficult. Even seemingly simple integrations are quite complex under the hood. Often, you won’t find problems until you’ve been using it for a while. But there are some things you can and should look for before installing a new integration.

  • Talk to other customers who have been using it for a while. There’s nothing like talking to someone with first-hand experience in a production environment. Ask about their experience with the integration, not just the app. Ask if they’ve had problems and how they were resolved.You can get references from the vendor but also find your own — reach out to the community on the Power of Us Hub and your local Salesforce Users Group. Ideally, find organizations that are similar to yours. If you use Nonprofit Starter Pack, you want to talk with other NPSP users. And you may want to connect with them privately to get the full scoop — people may be reluctant to criticize a product in a public forum.If you can’t find other users to talk to, the Salesforce integration may be new and untested. Proceed at your own risk; you may be one of the first guinea pigs.
  • Ask the vendor how the integration was built, and how it’s supported. As we discussed in our previous post, integrations are often farmed out to outside Salesforce developers. That’s not necessarily a bad thing, but you want to make sure then the vendor is prepared to provide good support, or that the developer is still available for questions.We recommend asking your salesperson the following questions when evaluating the app:
    1. Did you build the integration in-house, or hire an outside developer?
    2. If the latter, are the developers still available for support and troubleshooting?
    3. How well does your support staff know Salesforce and the integration? Can they help us solve problems with the integration?
  • Read the documentation first. Yes, all of it. If the documentation is good, you’ll learn a lot about how the integration works and if it does what you need it to. If the documentation isn’t good, or there is none, that’s a huge red flag. Good documentation isn’t just step by step configuration instructions — it should help you understand how the integration works so that you’re equipped to troubleshoot issues.
  • Check out the forums. Look through any public facing support forums or customer communities you can find. Note the kinds of questions people are asking, the problems they’re encountering, and the speed and quality of responses, including from the vendor. Look specifically for questions about the integration. Also, look for mentions in the Power of Us Hub and on Twitter (where people complain when they’re REALLY mad).
  • Test it in a Sandbox. Salesforce is as much platform as an app, and we all benefit from its flexibility. But that customizability means that just because an integration works for someone else doesn’t necessarily mean it’ll work for you. Sometimes the sync will run afoul of one of your custom validation rules, and cause errors. (Good reason to avoid custom validation rules!) Or your custom trigger will cause it to go over governor limits.

Sandbox testing won’t catch every potential problem, but it will give you an opportunity to configure the integration, review the data model, ensure that it’s compatible with your other apps, and confirm that the syncing works the way you expect. You may even want to get a full-data sandbox, to make sure that the integration can deal with the kind of data volume you’ll be generating in real use. (Just make sure there’s a way to start fresh with production data if you decide to move forward with the integration).

PS — Once you decide to pull the trigger, keep an eye on it! Set up some reports to help you catch problems and subscribe to them. Spot check records that are created or edited by the integration user. (You are using a separate integration user, right? It makes reporting on the activities of your integration much, much easier).