Salesforce admins love AppExchange apps. And, why not? They provide a boost to the native capabilities of a Salesforce org with little effort. However, many of those installed apps grow stale over time with new versions available that admins don’t even know about.
In this article, you’ll learn how to check if newer versions of your installed apps are available to upgrade and how to run a free security review of privately listed installed packages.
What are installed packages?
The Salesforce AppExchange launched in 2006, two years before the Apple App Store. According to Salesforce, it’s grown to over 7000 apps with over 10 million installs and 91% of Salesforce customers have installed at least one AppExchange app.
Salesforce AppExchange apps are installed packages that are distributed as managed or unmanaged:
- Managed packages are maintained by the publisher and can be upgraded
- Unmanaged packages have code that can be seen and modified but not upgraded
Salesforce AppExchange apps are not the only type of installed package. Installed packages can be created by any developer with access to a Salesforce org. This means packages could be installed from a third party, like a consultant or developer working in your org.
Are your installed packages security reviewed?
Because developers are able to create and install packages that haven't been published to the AppExchange, many installed packages have not undergone the Salesforce security review process.
Salesforce states, that “private listings do not go through a security review and administrators should inspect the application carefully before determining whether it should be installed within their organization.” To help, Salesforce shows you whether an installed package has undergone security review in the Setup > Installed Packages page. It’s definitely worth checking out—not only have these apps not undergone security review, but if there’s an upgrade you won’t know unless the publisher reaches out to you.
How to keep your installed packages up-to-date
So what happens when a publisher upgrades a package that’s on the AppExchange? If it’s managed, often the publisher will push the upgrade to your org and you get the latest version. Sometimes you have to initiate the package upgrade yourself. In those scenarios, you need to know there’s a newer version available. If you miss an announcement or there is none, you’re out of luck.
Even if you went through the time-consuming manual process of checking for yourself (by going into Setup > Installed Packages, checking the version number, and comparing to the AppExchange), there’s no guarantee the publisher even updated the AppExchange version number, as they have to do that manually. To put it simply, even if you checked the AppExchange, there still may be a newer version available.
Clearly, we have a big challenge in the ecosystem.
There needs to be a better way to help admins identify whether newer versions of public and privately listed installed packages are available. In the age of workflow and process retirement, those old packages may be slowing down your org with legacy declarative automation, nevermind the potential security vulnerabilities in custom code in out-of-date packages.
There is a better way, and yes, it’s automated!
Wouldn’t it be great if checking for new versions of packages and doing a custom code security review was automated?
Well, with the release of the free Hubbl Essentials scans, now it is. Hubbl Diagnostics Essentials provides a custom code security review that can be used to review not only your privately listed installed packages, but custom code in your entire org.
.png)
For package versioning, Hubbl Diagnostic’s unique aggregate view of the Salesforce ecosystem allows us to check all your installed packages against our database of package versions installed in other orgs. This “crowd-sourced” data set ensures that you’ll have a better chance of keeping your org up-to-date with the latest features, reduce security risks and speed up your org by removing legacy declarative automation like workflow and processes.
So, how many out-of-date packages are in your org?
