Someone on your team spots an AppExchange app that fills a gap in Salesforce, and the install button is right there. One click and it's in your org. That ease is exactly why packages deserve a second look first. A rushed install can mean weeks of cleanup, from permissions nobody planned to an upgrade that can't be rolled back. This guide covers how managed packages work, how to install and upgrade them safely, and what to check on security.
What Are Salesforce Managed Packages and How Do They Work?
A managed package is a bundle of Salesforce metadata that a publisher builds, locks and distributes, usually through AppExchange. It can hold custom objects, Apex code, Lightning components, flows, permission sets and whole apps. Everything in it carries the publisher's namespace prefix, which keeps its fields and classes from clashing with yours.
The difference from an unmanaged package is control. Salesforce's packaging documentation says unmanaged packages can't be upgraded, although everything inside stays editable after install. Managed packages work the other way: the publisher protects its code, ships new versions and can push upgrades to subscribers. Trailhead also notes that managed packages can be installed without worrying about your org's app, tab and object limits.
Businesses reach for a managed package when the need is common, like document generation, e-signature or payments, and a vendor has already solved it. Building from scratch only makes sense when your process is truly unusual.
How Do You Install a Managed Package in Salesforce?
Start on the publisher's AppExchange listing and check the publisher, the reviews and the editions it supports. Then follow these steps:
- Click Get It Now, log in and choose production or sandbox.
- Confirm the details and accept the terms.
- Choose who gets access.
- Click Install and wait for the email on large packages.
Salesforce gives three access choices. Install for Admins Only sets full object permissions on the installing admin's profile and any profile with Customize Application. Install for All Users sets access on every internal custom profile. Install for Specific Profiles lets you pick full or no access, profile by profile. If you're unsure, Trailhead suggests starting with admins only and opening access later, which is also our habit.
Once it's in, open Installed Packages in Setup and confirm the version. Then assign permission sets, check tabs and page layouts, and assign licences if the package is licensed. Salesforce also allows only one person in an org to install or upload a package at a time, so coordinate with your team.
What Should Businesses Check Before Installing a Salesforce Package?
Check compatibility first. Does the package support your Salesforce edition, and does it need another package installed before it? If your org carries heavy customisation, a salesforce consulting partner can map the package against it before anything is installed. Look at licences too: Salesforce tracks allowed and used licences under Installed Packages, so seats can run out quietly.
Then look at what the package touches. Does it read contact data, call an outside service or connect through OAuth? Those links matter more than they used to. In August 2025, attackers used stolen OAuth tokens from the Salesloft Drift integration to pull data from customer orgs, and Salesforce's own incident notice says it removed Drift from AppExchange and disabled the integrations.
Judge the publisher too: how long they've been listed, how current their release notes are and who actually answers support tickets. Whatever you decide, install in a sandbox first. AppExchange offers an Install in Sandbox option, and an hour of testing is cheap next to a production mistake.
How Do Salesforce Managed Package Upgrades Work?
Publishers release new versions, and you receive them in one of two ways. A push upgrade updates subscriber orgs automatically. Otherwise you install the new version yourself from the AppExchange listing or the publisher's email. Salesforce's developer docs say customers can ask to block push upgrades only when the publisher has switched that option on.
Your own work is mostly safe. Salesforce says subscribers can edit things like page layouts and help text without a later upgrade overwriting them. Profile settings are different, because developers can't upgrade them, so you may need to adjust profiles by hand afterwards. Permission sets do update. If a component is removed in a newer version, the old one usually stays behind marked as deprecated until an admin deletes it, and deleting it also deletes its data.
Here's the catch. Salesforce doesn't support rolling a managed package back to an earlier version. So test each upgrade in a sandbox with your integrations switched on, and schedule production for a quiet week.
How Secure Are Salesforce Managed Packages?
Every managed package listed on AppExchange has to pass Salesforce's security review, which mixes automated scans with a manual check by Salesforce's product security team. According to Noltic's 2026 guide, listed apps are re-reviewed every six months to two years. That's a solid filter, though it says nothing about how your org is set up.
Your own settings are the weak spot, and teams short on time often hire Salesforce developer help for a one-off access review, which costs far less than an incident. Whoever does it should install for admins first, give permission sets only to people who need them, and check what the package can reach through the API.
Open Connected Apps OAuth Usage in Setup and review every app listed. Arkus reports that since September 2025 Salesforce blocks uninstalled connected apps for most users by default, and Concret notes that new Connected Apps are off by default from Spring '26 as Salesforce moves toward External Client Apps.
Code is the awkward part. Apex inside a managed package is hidden from subscribers, so you can't read it yourself. Review what you can see instead: remote site settings, named credentials, permission sets and the data the package stores, and ask the vendor for its latest security review status. After each upgrade, glance at Setup Audit Trail and login history, because a new version can change what a package touches. Regular reviews matter for that reason: packages, integrations and your users all keep changing.
Should You Choose a Managed Package or Custom Salesforce Development?
Start with the gap, not the feature list. Write down what the business needs, then see how much of it a package covers. If it covers most of it at a sensible per-user price, take it, because it launches faster and the vendor carries the upgrades. If your process is unusual, or the package would need several workarounds to fit, custom crm development gives you control over fields, logic and integrations without waiting on someone else's roadmap.
Compare cost over three years, not three weeks. A package brings licence fees that grow with every seat, plus admin time for each upgrade. A custom build costs more up front, then needs a developer on call for fixes and each Salesforce release. Watch for overlap too. Two packages that both create leads, or one that repeats something Salesforce already includes, add licence cost and confusion. Review installed packages every quarter and remove what nobody uses, and export the data first, since uninstalling deletes it.
Are Salesforce managed packages safe to install?
Packages listed on AppExchange have passed Salesforce's security review, so they start from a good place. Whether one is safe in your org depends on its access settings, the integrations it opens and the vendor behind it. Test in a sandbox, install for admins first and review your connected apps.
Can you uninstall a Salesforce managed package?
Yes, from Installed Packages in Setup. Uninstalling removes the package's components and data, including custom fields, validation rules and workflow rules on its custom objects. Salesforce can save an export file, but Salesforce Help says it's kept for only 48 hours, so download it straight away. Salesforce also blocks the uninstall if something outside the package still references it.
Do managed packages update automatically?
Only if the publisher pushes the upgrade. Otherwise an admin installs the new version. Customers can ask to block push upgrades when the publisher has enabled that option, so check with the vendor.
Can you customise a managed package?
Only within limits. Salesforce says some components can't be changed after installation, and you can't edit the publisher's code. You can adjust page layouts and help text, assign permission sets and build your own flows and fields around the package.
What happens to data when a package is upgraded?
Existing records stay where they are. Salesforce says data and metadata are never deleted in a subscriber org without action from the customer, and new custom objects may need deploying after the upgrade. Removed components stay as deprecated until an admin deletes them.
Unsure whether a package fits your org? Our Salesforce team can review it before you install, test the upgrade path in a sandbox and tell you plainly if a custom build would serve you better. Get in touch before you click install.
