Managed, Unmanaged, and Unlocked Packages in Salesforce: Key Differences Explained

Key Insights 

‍

• Managed packages are built for commercial distribution, IP protection, licensing, and controlled upgrades.
• Unmanaged packages offer flexible customization, but updates must be managed separately.
• Unlocked packages support modular, source-driven development with version control and CI/CD.
• Managed packages support 1GP and 2GP, while unlocked packages are available in 2GP.
• The right Salesforce package depends on your distribution, customization, security, upgrade, and development needs.

‍

Salesforce managed package or unmanaged package: what fits the best? That’s the decision companies should make when starting a Salesforce solution. And not all of them know there is also an unlocked package, which creates real agony of choice.

The more they explore what each model brings to the table, the more they doubt themselves. And it’s ok as the Salesforce package type can affect how you build, distribute, update, and maintain your app. Plus, fixing the decision later may be tougher than getting it right from the beginning.

A different level of control over your code, updates, and distribution — all this differentiates Salesforce packages. Choose the wrong one, and you’ll have a headache when your product scales.

As Salesforce moved to the new unified AgentExchange marketplace, the ecosystem is opening new opportunities for AI-powered products. Choosing the right packaging model can help you build and scale those products without unnecessary limitations.

So, what variant works best for your business? Read our article, where we’ll figure out key points related to unlocked, managed, and unmanaged packages in Salesforce and explain which option makes the most sense for different AgentExchange product goals.

‍

‍

What Are Salesforce Packages?

A Salesforce packaging is a set of components you can mix together or use separately as a single unit. It contains custom objects, fields, code, automation, layouts, and other Salesforce resources. They add specific features or functionality.

Through AgentExchange or an installation link, you can create a package, add it to Salesforce, and share it within your company or other Salesforce users. Plus, you can set up packages across different Salesforce editions, depending on the type and its requirements.

Before we compare managed, unmanaged, and unlocked packages, let’s look at a few basic terms you’ll come across:

• Components: The building blocks of a package — custom objects, fields, Apex classes, flows, and other Salesforce metadata.
• Attributes: Properties that define how a component behaves. For example, a custom object may have an attribute that determines whether users can report on it.
• Package version: A specific edition of a package and the components it involves. Each new version covers changes or updates to the package.

Now that the basics are clear, let’s compare managed, unmanaged, and unlocked packages in Salesforce!

‍

What Are Unmanaged Packages in Salesforce?

Unmanaged packages in Salesforce are editable containers that allow packaged components to be modified and customized. These packages are ideal for scenarios where flexibility and customization are critical. 

For example, suppose a company develops an application for internal use and wants to share its components with other teams. In that case, unmanaged packages eliminate the need for manually copying and pasting each component. By simply sharing the package, the other teams can install and customize it as needed.

‍

Key features of unmanaged packages

‍

Unmanaged packages in Salesforce offer specific features that make them suitable for internal use and collaboration within teams:

• Customization. The team receiving the unmanaged package has full control over the components and can modify them freely to meet their specific requirements.
• Sharing. Unmanaged packages are typically used for internal sharing within an organization, making it easier to collaborate across teams without manually recreating the same components.
• Limited distribution. Unmanaged packages are not designed for public distribution on AgentExchange and are mainly for internal use.
• No automated upgrades. Since the Salesforce unmanaged package doesn’t support automatic updates, any changes or improvements need to be done manually by the team managing the application.

‍

Benefits

‍

Unmanaged packages bring several advantages for teams focused on flexibility and internal collaboration:

• With full control over your components after installation, your team can customize and adapt them to your needs without limitations.
• Unmanaged packages speed up sharing and deploying components across teams, allowing for faster iteration and development.
• Since unmanaged packages aren't distributed on AgentExchange, no licensing or distribution costs are involved.
• Sharing code and components through unmanaged packages improves teamwork and knowledge sharing among developers, making it easier to build solutions collectively.‍

‍

Limitations

‍

While unmanaged packages offer flexibility, they also come with certain limitations that developers should be aware of:

• Unmanaged packages don't protect intellectual property, as anyone can modify or reuse the components.
• You'll need to manually manage upgrades or improvements, which can become cumbersome as your application grows.
• Since there's no built-in version control, managing different versions of the components across teams can be difficult.
• These packages are mainly for internal use and can't be listed or sold on AgentExchange.
• Managing dependencies between components can be tricky, especially for larger projects, making unmanaged packages less ideal for more complex applications.

‍

What Is a Managed Package in Salesforce?

Managed packages in Salesforce are designed for developers who want to distribute applications and solutions to customers, often through AgentExchange. They come with a set of controls that protect the developers' intellectual property while allowing updates and version control for distributed applications. 

For example, if a software development company creates a custom product and wants to sell it on AgentExchange, it would use a managed package in Salesforce to distribute the solution to potential customers.

‍

Salesforce managed package options

‍

‍There are two main types of managed packages in Salesforce:

• First-generation managed packages (1GP). These older types of managed packages have been around for a long time and are commonly used for traditional AgentExchange apps. They support features like version control, Apex source protection, and distribution but have some limitations regarding flexibility and packaging improvements. For instance, 1GP packages may integrate less smoothly with newer Salesforce development tools and platforms, such as Salesforce DX (Salesforce's developer experience platform). Also, customization options are more restricted compared to newer package types. Once a 1GP package is installed, making changes or updates to the package's components is complicated, especially if you need to make systematic adjustments.
• Second-generation managed packages (2GP). This newer model provides more modern packaging options, such as better version control, simplified deployment in different environments, and easier management of package dependencies. It also integrates more smoothly into Salesforce DX.

‍

‍

Key features of managed packages

‍

Since managed packages are built for distribution, they provide all the essential functionality to support it: 

• Widespread distribution. Managed packages can be listed on Salesforce AgentExchange, making them accessible to a broad audience of potential customers.
• Apex source protection. Managed packages hide and lock Apex source code from subscribers, helping protect developers’ intellectual property.
• Version control. Managed packages come with built-in versioning, enabling developers to release new versions of their apps without disrupting current users.
• Controlled updates. They support package upgrades, allowing developers to release new versions that subscribers can install when needed.
• Unique namespace. Each managed package is assigned a unique namespace to avoid naming conflicts across Salesforce orgs.
• Different licensing model options. Managed packages support various licensing models, which allow developers to control how their apps are accessed and used. These models include per-user, per-org, subscription, usage-based, feature-based, and freemium.
• Sandbox environments. Managed packages can be tested in sandbox environments before they are distributed, ensuring a smoother user experience.

‍

Benefits

‍

What are the advantages of managed packages? Why do businesses opt for them?

• They offer a pathway to sell applications on AgentExchange, providing various pricing and licensing models.
• Managed packages can be distributed to multiple orgs and upgraded through Salesforce's package mechanisms, making it easier to scale as demand grows.
• With controlled updates, managed packages allow developers to push enhancements, bug fixes, and new features without requiring users to reinstall or manually update.
• Managed packages follow a standardized framework, ensuring that applications are consistently built, deployed, and maintained.

‍

Limitations

‍

Of course, managed packages have some drawbacks and limitations that should be considered.

• Developing a managed package can take longer due to the complexity of features like version control, Apex source protection, and AgentExchange requirements.
• Due to the time and effort involved, developing a managed package is usually more expensive than creating unmanaged packages.
• Listing a package on AgentExchange involves various fees, including security review fees and potential revenue-sharing arrangements. For paid apps, Salesforce AppExchange security review costs $999 per review attempt, while security reviews for free apps are free.
• Managed packages intended for AgentExchange distribution must meet marketplace requirements, which can add review and distribution considerations.
• Managed packages introduce additional packaging, versioning, security-review, and distribution requirements compared with simpler packaging models.

‍

What Are Unlocked Packages in Salesforce?

If you need modular, source-driven development, you should opt for unlocked packages in Salesforce. With it, teams can organize Salesforce metadata into smaller packages and deploy it across different orgs.

Let’s imagine: you’re planning a large Salesforce implementation with custom objects, flows, and Apex. With this model, you can split the functionality into separate unlocked packages. So you can develop, version, test, and deploy each of them independently.

‍

Key features of unlocked packages

‍

Unlocked packages offer several features that make Salesforce development more flexible:

• Source-driven development. Unlocked packages use a source-control-driven model, making them a natural fit for teams working with tools such as Git and Salesforce CLI.
• Modular development. Teams can divide a large Salesforce implementation into smaller packages based on functionality or business requirements.
• Flexible metadata. Unlike managed packages, the metadata in unlocked packages remains editable in the destination org.
• Version control. Each package version works like a snapshot of the package, making it easier to track and manage changes.
• Package dependencies. Unlocked packages can depend on other packages, which helps teams manage relationships between different parts of an implementation.
• Upgrade support. Developers can create new package versions and push upgrades to selected subscriber orgs when needed.
• Optional namespace. Unlocked packages can use a namespace, but it isn't required.
• CI/CD support. Their source-control-driven approach fits naturally into automated testing and deployment workflows.

‍

Benefits

‍

Why do Salesforce teams use unlocked packages? What do they bring to the table?

• Better modularity. Large Salesforce implementations can be divided into smaller, easier-to-manage packages.
• More flexible development. Teams can continue editing metadata after installation, giving them more control than managed packages.
• Easier collaboration. Source control allows developers to track changes and work on different parts of a Salesforce project.
• Modern DevOps workflows. Unlocked packages work well with Salesforce DX, CI/CD, and automated deployment processes.
• Controlled upgrades. Developers can create new versions and decide which orgs should receive an upgrade.

‍

Limitations

‍

Unlocked packages also have some limitations to consider:

• Less intellectual property protection. Unlike managed packages, unlocked packages are editable, so they aren't designed to protect proprietary code.
• More responsibility for the development team. Teams need to manage source control, dependencies, testing, and deployment processes themselves.
• Dependency management can become complex. Packages may depend on other packages or metadata, so teams need to plan their package structure carefully.
• Dev Hub dependency. The Dev Hub associated with an unlocked package becomes its owner. If that Dev Hub is deleted or expires, the package can stop working.
• Not primarily designed for AgentExchange apps. Unlocked packages are generally a better fit for internal Salesforce development and modular deployments than for commercial applications that need the protection and distribution model of managed packages.

‍

Managed vs. Unmanaged vs. Unlocked Packages in Salesforce: A Detailed Comparison

What’s the difference between managed and unmanaged packages in Salesforce? And how does unlocked packaging differ? Here are the main characteristics of each type:

‍

‍

Why You Need Salesforce Packages

We’ve already explained managed vs. unmanaged packages, along with unlocked ones. Now it’s time to see why they’re vital for businesses. 

• Packages help organize and bundle related components, making them easier to manage and deploy.
• You can create reusable components for multiple projects, saving time and effort in future developments.
• Packages facilitate the deployment of components between different Salesforce orgs, making moving from development to production environments simpler.
• If you're distributing an app on Salesforce AgentExchange, packages allow you to bundle your solution and easily share it with customers.
• Packages enable you to track changes and manage different versions of your components, ensuring you maintain control over updates and bug fixes.

‍

How to Choose Between Salesforce Managed, Unmanaged, and Unlocked Packages

Generally, the decision between these two options depends on whether ISVs or your internal team will develop the application. However, other factors should also be taken into account. Unlocked packages add a third option, especially for teams that need modular development, source control, and flexible deployment.

‍

Package customization and stability

‍

If your app requires extensive customization by the end user, such as adjusting components or modifying code to fit unique internal processes, an unmanaged package is the better option. It allows full control and flexibility post-installation.

However, if security and maintaining control over the code are more important, particularly when distributing your app to external users, managed packages are a better fit. They protect your intellectual property with features like Apex source protection and ensure that users can't alter the underlying code.

Unlocked packages combine editable components with a structured, source-driven development and versioning model. So teams can customize them while still managing the package through a structured, source-driven development process.

‍

Distribution

‍

Unmanaged packages are ideal for internal sharing within your organization or between specific teams. They aren't designed for public distribution, so if your goal is to distribute or sell the app on Salesforce AgentExchange, you will need a managed package.

Managed packages are built for commercialization. They allow you to list your app publicly on AgentExchange and reach a wider audience, providing potential revenue opportunities.

Unlocked packages can be used for both internal and external distribution, but they aren't the package type used for AgentExchange listings. They are a good fit when you need to distribute a customizable application without locking its components.

‍

Upgradeability

‍

A managed package is a suitable option if your app requires frequent updates or ongoing feature additions. Managed packages support package upgrades, allowing subscribers to install new versions when needed rather than automatically receiving every update.

‍

On the other hand, unmanaged packages lack controlled upgrade mechanisms, meaning that users must manually update components each time a new version is released. It can be burdensome and time-consuming, especially for larger applications.

Unlocked packages support versioning and upgrades, making them suitable for teams that need to evolve a package over time. They can also be used with modular package dependencies and modern development workflows.

Cost

‍

Unmanaged packages are generally more cost-effective. They don't involve AgentExchange listing fees, security review fees, or ongoing revenue-sharing agreements, making them a cheaper solution for internal use.

Managed packages come with additional costs — development, testing, and distribution. To list a paid managed package on AgentExchange, you'll need to cover a $999 security review fee per submission and agree to a 15% revenue share with Salesforce (25% under the OEM model).

Unlocked packages can be a cost-effective option when you don't need AgentExchange distribution. They don't go through the AgentExchange Security Review, which makes them suitable for internal development and distribution outside the AgentExchange.

‍

Organization size

‍

The size of your organization or the intended audience can also impact your choice. Managed packages are better suited for enterprise-wide deployments, where control, security, and scalability are essential. Managed packages provide tools for managing large-scale distribution, licensing, and controlled updates across many users. 

An unmanaged package offers more flexibility and is more straightforward to deploy for smaller projects or internal use, especially when scalability and formal licensing aren't necessary.

Unlocked packages are well suited to teams that use source control, CI/CD, and modular development. They can work for both internal projects and external applications when editable components and flexible development are important.

‍

Which Salesforce Package Should You Choose?

The right package depends on how you plan to develop, distribute, and maintain your solution.

‍

Choose a managed package if...

‍

• you're building a commercial product
• you want AgentExchange distribution
• you need controlled upgrades
• you need IP protection
• you need licensing

‍

Choose an unmanaged package if...

‍

• the solution is mainly for internal use
• customers or teams need to customize components
• you don't need managed upgrades
• you're sharing components between teams
• you need a simple one-time distribution

‍

Choose an unlocked package if...

‍

• you want source-driven development
• you need modular packages and dependencies
• your team uses version control and CI/CD
• components should remain editable after installation
• you need versioning and upgrades without locking the components

‍

Our Tips for Getting the Most Out of Salesforce Packages

Whether you're using managed, unmanaged, or unlocked packages, the following tips will help ensure your development process is efficient, scalable, and easy to maintain.

‍

1. Break down your package into smaller, manageable components

‍

When creating a Salesforce package, it's important to divide the solution into smaller, modular components. This breakdown makes it easier to manage, update, and debug. For example, if an issue arises with a single component, you can address it without disrupting the entire package. Smaller components also promote reusability across other projects, saving time in the long run.

‍

2. Use consistent and meaningful names for components

‍

Naming conventions are essential for ensuring clarity and avoiding confusion. By using consistent and descriptive names, you help future developers, admins, or even your team quickly understand what each component does. For example, naming a custom object Invoice_Tracker is more descriptive than a generic name like CustomObject_1. Consistency helps ensure your package is organized and easy to understand.

‍

3. Document the package's contents, dependencies, and installation instructions

‍

Comprehensive documentation is crucial for helping users understand how to install and use your package. Make sure you list all components, dependencies, and detailed installation steps. These records reduce the likelihood of installation issues and ensure that users know how to troubleshoot potential problems. Proper documentation also helps new team members get up to speed quickly.

‍

4. Test the package in different environments

‍

Before deploying your package, always test it in multiple environments (e.g., sandbox, production) to identify potential issues that may arise in different orgs. Each Salesforce environment has its own unique configuration, and what works in one may not function in another. Comprehensive testing helps ensure the package will perform as expected across all environments, reducing support requests and installation issues.

‍

5. Utilize a version control system to track changes and manage different package versions

‍

A version control system like Git allows you to track changes to the package's components and revert to earlier versions if needed. It provides a record of who made changes and when which is helpful when debugging or auditing. Version control also supports collaboration between developers, enabling multiple team members to work on the package simultaneously without overwriting each other's work.

‍

6. Choose a suitable versioning scheme to indicate changes in the package

‍

A consistent versioning scheme, like semantic versioning (e.g., 1.0.0, 1.0.1), helps developers and users understand the significance of changes in each version. For example, a major version update (1.x to 2.x) indicates that significant changes have been made, while a minor update (1.0 to 1.1) might indicate small improvements or bug fixes. This clarity ensures that users know what to expect when they upgrade.

‍

7. Document changes in each package version to inform users

‍

Every time you release a new package version, include release notes documenting the changes. These notes help users understand what has been fixed, improved, or added in the latest version. This transparency reduces confusion and allows users to assess whether they want to upgrade immediately or wait for a later version.

‍

8. Regularly back up your package to prevent data loss

‍

Regular backups of your package components are critical to avoid data loss. Whether it's a system failure, human error, or an unforeseen issue during a package upgrade, having backups ensures you can recover your package quickly. Backups are essential when dealing with complex projects that involve many dependencies and custom components.

‍

9. Carefully manage dependencies between packages to avoid conflicts

Poorly managed dependencies can lead to conflicts that break functionality. It's essential to identify and track all dependencies within your package and ensure they are appropriately managed. If your package relies on another package or specific features, you must ensure that the dependencies are clearly stated and updated as necessary to avoid compatibility issues.

‍

10. Use tools like Schema Builder and Dependency API to visualize and manage dependencies

Salesforce provides tools like Schema Builder and Dependency API to help you visualize and manage the relationships between objects and components in your package. These tools allow you to see how different package elements are connected, making it easier to identify potential conflicts or optimize your package's structure.

‍

How Noltic Helped a Leading Textiles Manufacturer Speed Up Their Operations with a Managed Salesforce Package

Our client, a UK-based technical textiles manufacturer founded in 1954, operates in over 50 countries. They needed a better system to manage their growing production and inventory processes. The client chose Salesforce to build a unified ERP system to automate production, track inventory, and reduce waste. Their previous manual tracking system led to inefficiencies and unpredictable costs.

‍

Why we opted for a managed package

‍

We implemented a managed Salesforce package to allow easy updates and scaling as their operations grew. The package provided the flexibility to add new features without downtime and ensured controlled upgrades and intellectual property protection.

‍

‍

Results achieved

• Built a full-cycle ERP system.
• Improved inventory management and reduced material waste.
• Enhanced financial visibility and client balance tracking.
• Provided real-time insights for better production planning.

‍

Why Noltic for Salesforce Implementation and Development

Picking the right Salesforce package is more than making the choice between managed, unmanaged, and unlocked packages. You need an experienced team who can help you close more deals and build stronger relationships through the Sales, Service, Marketing, and Financial Services Cloud.

With 160+ Salesforce projects across Sales, Service, Marketing, Revenue, Data, and AI under our belt, Noltic brings disconnected processes together and makes them easier to manage.

At Noltic, we specialize in AgentExchange product development outsourcing, successfully implementing managed, unmanaged, and unlocked packages and have proven client case studies. 

‍

Whether you're looking to build a custom solution or scale your operations, our team has the expertise to guide you through the process and deliver a customized solution designed for your particular needs.

‍

‍

‍

FAQs

‍

Can I convert an unmanaged package to a managed package?

‍

No, Salesforce does not support converting unmanaged packages to managed packages. Unmanaged packages are designed for flexibility and customization by the end-user, while managed packages offer more control, protection, and update features. If you need to shift to a managed package, you'll have to rebuild the package from scratch. This process includes creating a new managed package, assigning a namespace, and migrating the necessary components manually from the unmanaged package.

‍

‍What is a namespace, and why is it important?

‍

A namespace is a unique prefix assigned to all components in a managed package. Using this feature ensures that the components in your package do not conflict with components from other packages or those in a customer's Salesforce org. For example, if you have a custom object named "Invoice" in your package, Salesforce will automatically add your namespace as a prefix (e.g., MyApp__Invoice), making it unique. This is particularly important when you distribute your package on AgentExchange, where it may be installed alongside other packages that could contain components with the same names. The namespace helps to:

• Avoid naming conflicts in shared environments.
• Protect your intellectual property in managed packages.
• Ensure your package works smoothly in multi-package orgs.

‍

Can I have multiple unmanaged packages in an org?

‍

Yes, you can have multiple unmanaged packages in a single Salesforce org. However, unmanaged packages do not have namespaces, so naming conflicts may occur if different packages use the same component names (e.g., objects, fields, Apex classes). Additionally, because unmanaged packages allow complete customization, managing updates and changes across multiple packages can become complex. Careful planning ensures smooth integration between components from different unmanaged packages.

‍

What are the benefits of listing a package on the AgentExchange?

‍

Listing a managed package on Salesforce AgentExchange provides several key benefits:

• You can distribute your app to a worldwide customer base and choose from various licensing models, offering a new revenue stream.
• AgentExchange is a unified marketplace with 13,000+ solutions, allowing you to reach a wide audience of Salesforce users worldwide.
• Managed packages support version control and package upgrades, allowing developers to release new versions and subscribers to install eligible upgrades when needed.
• Your package will undergo Salesforce's security review, which ensures that it meets Salesforce's standards for security and performance, giving potential customers confidence in your product.
• Managed packages allow you to easily scale your application across many users and environments, as updates and licensing are centralized.

‍

How to create a managed package in Salesforce?

‍

For new development, Salesforce recommends second-generation managed packages (2GP), which are created and managed using Salesforce CLI rather than the Setup > Packages UI. If you’re working with a legacy first-generation managed package (1GP), you can still create and manage it through Setup.

To create a 2GP managed package in Salesforce, follow these steps:

1. Set up your Salesforce DX environment. Install Salesforce CLI and authenticate to your Dev Hub org. Make sure you have the necessary permissions to create and manage packages.
2. Create a namespace. Register a namespace for your managed package. A namespace is required for managed packages and ensures your components are uniquely identified.
3. Create a Salesforce DX project. Use Salesforce CLI to create a project and organize the metadata you want to include in your package.
4. Create the package. Use Salesforce CLI to create a 2GP managed package, specifying the package name, namespace, and other required details.
5. Add and configure your components. Include the custom objects, fields, Apex code, flows, and other Salesforce components that make up your solution.
6. Create a package version. Use Salesforce CLI to create a version of your package. Follow a consistent versioning scheme to distinguish major updates from minor improvements and bug fixes.
7. Test the package. Install and test the package version in a sandbox or scratch org to verify that it works as expected before distributing it to subscribers.
8. Promote and distribute the package. Once the package has been tested, promote the version for release and, if desired, submit the package for AgentExchange listing. Salesforce requires packages to pass a security review before they can be publicly listed.
9. Manage licensing and subscriber access. Use Salesforce's licensing capabilities to control who can access and use your managed package.

Note: The steps above describe the modern 2GP approach. For legacy 1GP managed packages, package creation and management can be performed through Setup → Packages.

‍

How to create an unmanaged package in Salesforce?

‍

To create an unmanaged package in Salesforce, follow these steps:

1. Sign up for a Salesforce Developer account or use your existing Developer org.
2. Go to Setup > Packages, and click New. Name your package and provide a description. Leave the Managed checkbox unchecked to create an unmanaged package.
3. Add the necessary components (e.g., objects, fields, workflows, Apex classes) by clicking Add in the package details. Unmanaged packages don't require a namespace, so the components will be identified only by their names.
4. Although unmanaged packages don't have built-in version control, you can still manually track changes and versions for internal purposes.
5. After the package is created, click Upload to share it with others. Since unmanaged packages can't be listed on AgentExchange, you will need to share them directly with users or teams. Users can install the package into their Salesforce orgs for internal use, where they can further customize the components.
6. Remember, unmanaged packages do not support automatic updates. If changes are needed, users will have to manually update or reinstall the package.

‍