Salesforce AppExchange is the largest enterprise cloud marketplace, featuring over 7,000+ applications. Solutions have been installed more than 10 million times, helping businesses across industries streamline their operations and optimize workflows.
If you're considering developing and managing your own applications on this platform, one of the key decisions you'll face is choosing between managed and unmanaged packages. They are like essential building blocks, simplifying the development process and determining how your app is distributed and maintained.
At Noltic, we have extensive experience developing solutions for AppExchange and unmatched expertise: Only 11 teams hold the highest Salesforce PDO Expert badge in the world—Noltic is one of them. Our team has successfully developed 3 on-house AppExchange apps, contributed to 15+ apps as trusted outsource partners, and acquired 75+ Salesforce certifications in Platform Development, Platform App Building, and App Architecture.
This hands-on experience has given us a deep understanding of AppExchange app development and how to choose the right approach based on your product's goals. In this article, we will guide you through the differences between managed and unmanaged packages in Salesforce, drawing on our expertise to help you make an informed decision for your AppExchange product.
Why you need Salesforce packages
Salesforce packages are containers that bundle and distribute related components, such as custom objects, fields, and Apex code. They allow developers to manage, share, and deploy their applications more efficiently within and between Salesforce orgs. Here's why they are essential:
- 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 AppExchange, 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.
Salesforce packages come in two types: managed and unmanaged, each serving different purposes depending on your needs.
Overview of unmanaged packages in Salesforce
Unmanaged packages in Salesforce are open-source containers that allow anyone to view, modify, and use the packaged components. 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 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 AppExchange and are mainly for internal use.
- No automated upgrades. Since unmanaged packages don'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 AppExchange, 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 AppExchange.
- Managing dependencies between components can be tricky, especially for larger projects, making unmanaged packages less ideal for more complex applications.
Overview of managed packages in Salesforce
Managed packages in Salesforce are designed for developers who want to distribute applications and solutions to customers, often through AppExchange. 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 AppExchange, it would use a managed package to distribute it to potential customers.
Salesforce managed package options
There are two main types of managed packages in Salesforce:
- First-generation managed packages (1GMP). These older types of managed packages have been around for a long time and are commonly used for traditional AppExchange apps. They support features like version control, code obfuscation, and distribution but have some limitations regarding flexibility and packaging improvements. For instance, 1GMP 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 1GMP 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 (2GMP). 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 AppExchange, making them accessible to a broad audience of potential customers.
- Code obfuscation. Protects developers' intellectual property by making the package's code challenging to reverse-engineer.
- Version control. Managed packages come with built-in versioning, enabling developers to release new versions of their apps without disrupting current users.
- Automatic updates. Once an app is installed, updates can be pushed to users automatically, ensuring they always have the latest version.
- 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
- Managed packages offer a pathway to sell applications on AppExchange, providing various pricing and licensing models.
- Applications developed using managed packages can be distributed to multiple users without manual intervention, making it easier to scale as demand grows.
- With automatic 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
- Developing a managed package can take longer due to the complexity of features like version control, code obfuscation, and AppExchange requirements.
- Due to the time and effort involved, developing a managed package is usually more expensive than creating unmanaged packages.
- Listing a package on AppExchange involves various fees, including an upfront security review fee and ongoing revenue-sharing agreements. The security review typically costs around USD 2,700, and Salesforce takes 15% of the revenue from app sales.
- Managed packages rely on AppExchange for distribution, which can limit control over how the application is marketed and sold.
- Once a managed package is created and distributed, it becomes tied to Salesforce's platform, making it difficult to migrate or switch platforms in the future.
Managed VS unmanaged packages in Salesforce: a detailed comparison
Here are the main differences between managed and unmanaged package in Salesforce:
How to choose between Salesforce managed and unmanaged 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.
Choosing between 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, managed packages are a better fit if security and maintaining control over the code are more important, particularly when distributing your app to external users. They protect your intellectual property with features like code obfuscation and ensure that users can't alter the underlying code.
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 AppExchange, you will need a managed package.
Managed packages are built for commercialization. They allow you to list your app publicly on AppExchange and reach a wider audience, providing potential revenue opportunities.
Upgradeability
A managed package is the superior option if your app requires frequent updates or ongoing feature additions. Managed packages support automatic updates, ensuring users always have the latest app version without reinstalling or manually applying changes.
On the other hand, unmanaged packages lack automated 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.
Cost
Unmanaged packages are generally more cost-effective. They don't involve AppExchange listing fees, security review fees, or ongoing revenue-sharing agreements, making them a cheaper solution for internal use.
Managed packages, however, come with additional costs, such as development, testing, and distribution expenses. For example, to list a managed package on AppExchange, you'll need to cover the USD 2,700 security review fee and agree to a 15% revenue share with Salesforce.
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 better tools for managing large-scale distribution, licensing, and automatic 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.
Our tips for using Salesforce packages
Whether you're using managed or unmanaged packages, the following tips will help ensure your development process is efficient, scalable, and easy to maintain.
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.
Use consistent and meaningful names for components
Naming conventions are essential for ensuring clarity and avoiding confusion. Using consistent and descriptive names helps 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.
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.
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.
Utilize a version control system (e.g., Git) 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.
Choose a suitable versioning scheme (e.g., semantic versioning) 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.
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.
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.
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.
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 we accelerated operations for a leading textiles manufacturer 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 automatic upgrades and intellectual property protection.
.webp)
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.
Key Takeaways
When deciding between managed and unmanaged packages in Salesforce, the choice depends on your specific needs:
- Choose a managed package if you require easy updates, scalability, and secure distribution on AppExchange. Managed packages are ideal for applications that will be sold or distributed widely, offering protection for intellectual property and automatic updates for end-users.
- Opt for an unmanaged package if you focus on internal customization and need flexibility in modifying components post-installation. Unmanaged packages are suited for internal use and simpler projects without the need for public distribution.
At Noltic, we specialize in AppExchange product development outsourcing, successfully implementing managed and unmanaged packages for clients across various industries. 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 AppExchange, 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 AppExchange?
Listing a managed package on Salesforce AppExchange 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.
- AppExchange is the largest cloud marketplace, allowing you to reach a wide audience of Salesforce users worldwide.
- Managed packages support version control and automatic updates, ensuring users always have the latest features without requiring manual reinstallation.
- 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?
To create a managed package in Salesforce, follow these steps:
- Sign up for a Salesforce Developer account or use your existing Developer org.
- Go to Setup > Packages > Developer Settings to create a namespace. It is required for managed packages and ensures your components are uniquely identified.
- In Setup, navigate to Packages, click New, and give your package a name and description. Select Managed for the package type.
- Add the components (e.g., custom objects, fields, Apex code) you want to include in your package by clicking Add in the package details.
- Assign a version number for your package. Use a versioning scheme (e.g., semantic versioning) to differentiate major updates from minor improvements.
- Test your package in a sandbox environment to ensure that it works as expected across different environments.
- Once tested, click Upload to package it and, if desired, submit it to AppExchange for listing. Salesforce will require your package to pass a security review before it can be made public.
- Use Salesforce's licensing management system to control who can access and use your package.
How to create an unmanaged package in Salesforce?
To create an unmanaged package in Salesforce, follow these steps:
- Sign up for a Salesforce Developer account or use your existing Developer org.
- Go to Setup > Packages, and click New. Name your package and provide a description. Leave the Managed checkbox unchecked to create an unmanaged package.
- 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.
- Although unmanaged packages don't have built-in version control, you can still manually track changes and versions for internal purposes.
- After the package is created, click Upload to share it with others. Since unmanaged packages can't be listed on AppExchange, 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.
- Remember, unmanaged packages do not support automatic updates. If changes are needed, users will have to manually update or reinstall the package.
.webp)
together