The Salesforce AppExchange, with its diverse population of over 3400 strenuously vetted 3rd party packages, is a big part of what makes this CRM so attractive to businesses across market sectors. No matter what process your company is looking to optimize or automate, the AppExchange is an easily accessible one-stop-shop for Salesforce software solutions.
Just make sure you go in with a plan.
When you get home from the grocery store and realize you got margarine instead of butter by accident, the stakes are pretty low (unless you were REALLY counting on those cookies), but choosing a 3rd party package for your Salesforce org isn’t a decision to take lightly. The wrong call doesn’t just waste the cost of purchase, but also runs the risk of breaking your org down the line. You could end up with useless overlapping functions obstructing your goals, or realize too late that key aspects of your workflow are built on a shaky foundation that isn’t properly maintained or updated by its developers.
Especially when you’re just starting out, the selection on the AppExchange can be daunting, and there’s an array of factors to evaluate before making a final purchase - even if a package makes a stellar first impression. Follow these five simple steps, and you’ll have a buttery smooth Salesforce AppExchange shopping experience that sets your org up for sweet success:
1. Invest in Managed Packages
Before you even enter the AppExchange, you may be tempted to look into unmanaged packages as an option for your org, and while there are factors that attract some businesses to unmanaged packages - they don’t make up for the potential risks.
Unmanaged packages are open source templates that developers can use when designing their own apps. They can’t be published in the AppExchange, and they’re usually free. The customizability that comes with these ready-made templates can be a great asset in the right situation, and once you see the $0 price tag, you may be tempted to see if you can make it work. However, if you’re not paying for the product, the team that made it likely isn’t getting paid either - so you can expect to spend your own overhead to maintain and update the package.
On top of this hidden cost, even if you do manage to hunt down a well-supported unmanaged package, these templates still present both technical and security risks in most sophisticated orgs. From the technical side, unmanaged packages are likely coming with tons of extra code you don’t need that can cause unforeseen problems when mixed into your org. If you customize the unmanaged package, you also cannot upgrade it, as the latest version of the unmanaged package might break your customizations, forcing you to fully uninstall and reinstall if you want to use new features as they’re added, and this process presents a slew of opportunities for breakage.
From the security side, unmanaged packages can also add vulnerability to your org, since they haven’t had to pass the kinds of security reviews required by the Salesforce AppExchange.
Essentially, step one of your evaluation process is more of a don’t than a do. Don’t go out of your way to seek out unmanaged packages, even though they’re customizable and cheap. The best products for any sophisticated org can always be found in the Salesforce AppExchange, where you can find fully secure, continuously-updated managed packages for any solution you can imagine.
2. Check the Age of Your Package
This step takes seconds to execute, and could save you months of headaches. Like the bouncer of your Salesforce org, you should be checking the age of every package carefully to make sure it’s “mature” enough to enter.
If a package has existed for less than a year, it’s extremely high risk. The newer the package, the less you’ll be able to tell about its effectiveness, support system, or update schedule. In the 2-3 year range, you can get a much better picture of how a package will perform and if the team behind it is reliable.
At 5 years and up, if the package is still getting regular updates, you know it’s a solid option.
3. Check Past Updates and Versions
Speaking of regular updates, there’s no better indicator of a package’s level of developer support than how often it’s updated. Salesforce updates their core system 3 times per year. Not every update will necessarily affect your package’s functionality, but the longer your package has to go without developer attention in this constantly-shifting environment, the higher the likelihood that a core system update will disrupt your org.
Before installing a package, make sure that it’s been updated in (at the very least) the last 12 months. Any longer than this, and you’ll know that when it comes to bug fixes, new feature requests, and aligning with core Salesforce… you’re on your own.
If you find a package that’s been updated in the last 6 months, that’s a strong indicator that it has decent developer support, which should be a crucial part of your risk analysis. You don’t want to build your org around a product whose developers have a “set it and forget it” attitude.
4. Call Customer Support
Now that you know your potential purchase has developer support, it’s time to evaluate if you can count on customer support. Every package comes with a learning curve, especially if you’re choosing something complex and impactful to your overall org, you’re going to want to be able to bank on some level of help when you run into snags. It’s hard to overemphasize how important this support can be in the first 3 months of configuration.
To get a real picture of the app’s customer support, you’re going to need to talk to a real person. This means making a phone call, ideally to the support or contact number provided in the package’s listing on AppExchange. If you have to hunt for contact information, or can’t find any, that’s a big red flag.
Once you get a customer support person on the phone, make sure you ask about what’s available to customers post-purchase and what customer support packages they offer. Finally, ask about the product, the team, and if they’re making regular updates.
Try to generally get a feel for whether or not there’s a layer of people working for this company that will help you set up, operate, and troubleshoot their product… because in all likelihood, at some point you’re going to need them.
5. Perform a Demo Evaluation with an Experienced Technical Resource
If the package you’re considering has passed the first 4 steps, it’s time to get your hands on it with a demo to better evaluate how it’s built, if its features function as advertised, and if it will fit well into your existing org.
Any reputable app will give you 30 day demo access where you can download it into a sandbox and test how it functions. If the app in question doesn’t offer some kind of demo period, you have to ask yourself what they’re trying to hide. Don’t buy a package you can’t test first, period.
Once you have demo access, you’re going to want to task your most experienced Salesforce resource with performing the evaluation. Using this demo access, your resource will install the program, open all the applications included, and make a MVP (Minimum Viable Product) to evaluate if this package can successfully meet your org’s needs.
If your resource runs test data through the MVP and sees that the package not only does what it’s advertised to do, but that it succeeds under the unique conditions that your workflow requires, then (and only then) you’re ready to make your purchase.
Struggling to find the package that’s optimized for your needs on AppExchange?
Cloud Pacific can design a totally custom solution for your org. Contact us here to start a conversation and find out what we can build for you.