Managed Package
Term 161 of 314 · Technology
In one sentence
A managed package is a container of Salesforce code and configuration, versioned and distributed through AppExchange, that keeps its intellectual property hidden and is updated in a controlled way in every org that installs it.
Reviewed by Juan Manuel Garrido
Co-founder of VantegrateLinkedIn
Managed Package definition
A managed package is the standard way an application or component built on Salesforce is packaged, distributed and versioned. It bundles Apex code, Lightning components, custom objects, flows and metadata into an installable unit that a customer can add to their org in a few clicks, usually from AppExchange.
What sets a managed package apart from an "unmanaged" one is the control the developer (ISV or partner) retains: the source code stays hidden, components carry a reserved namespace prefix, and the publisher can release upgradeable versions that roll out without breaking the customer's customizations. It is the model partners use to build commercial products on the platform, and it is part of the development work Vantegrate takes on.
A managed package solves a specific problem: how to deliver software built on Salesforce to many customers while keeping the ability to version, protect and update that software centrally. Instead of copying and pasting components org by org, the developer packages everything (Apex, Lightning Web Components, objects, fields, flows, pages, permission sets) into a single signed, publishable unit.
How it works in practice
The publisher develops in a special Developer Edition org with a registered namespace, for example "acme". Every component in the package gets that prefix (acme__Invoice__c) to avoid collisions with the customer's objects or with other packages installed in the same org. When the package is ready, the publisher releases a version (1.0, 1.1, 2.0) and gets an installation link or an AppExchange listing. The customer installs that version in their org; later, when the publisher releases an improvement, it can send an upgrade (push or pull) that preserves existing data and customizations.
Why it matters
The core value is the controlled upgrade model. In a managed package, the publisher decides which components the customer can modify and which stay locked; that way it can fix a bug or add a feature without the customer losing what they configured on top. For a company that buys an app on AppExchange, this means it gets continuous improvements without reinstalling anything. For the partner that sells it, it means protecting its intellectual property and maintaining a customer base on a single codebase.
Managed vs unmanaged
The difference is decisive, and it is worth being clear on it before choosing a format:
| Aspect | Managed package | Unmanaged package |
|---|---|---|
| Source code | Hidden and protected | Visible and editable |
| Namespace | Reserved and fixed | No namespace |
| Upgrades | Versioned and pushable | Not upgradeable (it is a template) |
| Typical use | Commercial products on AppExchange | Templates, samples, open source |
| Who controls it | The publisher (ISV/partner) | Whoever installs it |
In short: if the goal is to distribute a product and maintain it, use managed; if it is to share a starting point that everyone will modify freely, use unmanaged.
A concrete example in Latin America
An Argentine software company builds an e-invoicing module that connects Salesforce with ARCA (Argentina's federal tax agency, formerly AFIP). It packages it as a managed package with the namespace "factarg", publishes it on AppExchange, and distributors in Córdoba, Rosario and Buenos Aires install it. When ARCA changes the invoice schema, the publisher releases version 2.3 of the package and the upgrade reaches all three distributors without any of them touching their object configuration or losing their own validation rules. Without the managed model, every regulatory change would require manual work customer by customer.
Common mistakes
- Confusing a managed package with a simple metadata export: a managed package requires registering a namespace, which is irreversible once it is linked to the development org.
- Thinking the customer can edit the installed code: in a managed package, the Apex stays protected and only what the publisher exposes as configurable can be changed.
- Forgetting tests: Salesforce requires Apex test coverage before you can package, and the customer's governor limits still apply to the package code.
- Underestimating the security review: publishing on AppExchange requires passing the Salesforce Security Review, which can take weeks.
Two generations of packaging coexist: first-generation managed packages (1GP, tied to a packaging org) and second-generation packages (2GP), managed or unlocked, which are source-driven and better integrated with modern version control. For new commercial products, the path Salesforce recommends is second generation.
FAQs about Managed Package
What is a managed package in Salesforce?
What is a managed package in Salesforce?
A managed package is an installable container that bundles Salesforce code, objects, flows and metadata into a versioned, distributable unit. Unlike an unmanaged package, it keeps the source code hidden, uses a reserved namespace and lets the publisher release upgrades that roll out to the orgs that installed it without breaking their customizations. It is the format partners use to sell applications on AppExchange.
What is the difference between a managed and an unmanaged package?
What is the difference between a managed and an unmanaged package?
In a managed package, the source code is hidden, components carry a fixed namespace and the publisher can release upgradeable versions; it is used to distribute commercial products. In an unmanaged package, the code is visible and editable, there is no namespace and it cannot be updated centrally: it works as a template or starting point that anyone can modify freely. The choice depends on whether you want to maintain and protect the product or just share a sample.
What is a managed package used for?
What is a managed package used for?
It is used to package an application built on Salesforce and distribute it to many customers while keeping control over its code and versions. It lets you protect intellectual property, avoid collisions with other components through a namespace and, above all, deliver continuous improvements and fixes through versioned upgrades, without each customer having to reinstall or reconfigure anything.
How do you publish a managed package on AppExchange?
How do you publish a managed package on AppExchange?
The developer works in an org with a registered namespace, groups the components into the package and ensures the Apex test coverage Salesforce requires. Then they create a package version, submit it to the Salesforce Security Review and, once approved, list it on AppExchange with an installation link. From there, customers install it in their org and receive the new versions the publisher releases.
What is the namespace in a managed package?
What is the namespace in a managed package?
The namespace is a unique prefix reserved by the publisher, for example acme, that is added to every component in the package (acme__Object__c). It keeps those components from clashing with the customer's objects or with other packages installed in the same org. It is mandatory for managed packages and, once linked to the development org, it is irreversible, so choose it carefully.
We bring this to your Salesforce
Salesforce implementation, integration and support for LatAm companies, focused on the team actually using it instead of going back to spreadsheets. Tell us where your org stands.
Related terms
- AppExchangeAppExchange is Salesforce's official marketplace: an online store with apps, components and certified consultants that extend the platform. It lets you install ready-to-use solutions, free or paid, without coding from scratch.
- ApexApex is Salesforce's proprietary, object-oriented programming language, similar to Java, that runs on Salesforce's servers. It lets you add custom business logic (triggers, classes and integrations) when declarative tools such as Flow are not enough.
- Governor LimitsGovernor limits are the execution limits Salesforce imposes on each transaction (queries, records processed, API calls, CPU) to protect the shared resources of its multi-tenant architecture, where many customers run on the same infrastructure.
- Salesforce SandboxA Salesforce sandbox is an isolated copy of your production org where you can develop, configure and test changes without affecting real users or live data, before promoting those changes to production in a controlled way.
- Marketing CloudMarketing Cloud is Salesforce's digital marketing platform for creating, automating and personalizing campaigns at scale across email, SMS, web, push and social, segmenting audiences with customer data and orchestrating automated journeys based on behavior.
- MiddlewareMiddleware is software that acts as a bridge between two or more systems, translating, orchestrating and routing data so that different applications (for example an ERP and a CRM) can communicate without connecting directly.
Related questions
Salesforce
Salesforce implementation, integration and support for LatAm companies, focused on real team adoption.
How Salesforce solves itFive AI products that work on top of the CRM you already use. They don't replace your system: they add the layer you do by hand today.
