Forcetalks

Tag: Patch Versions

  • Managed and Unmanaged packages in Salesforce in 2023 | All You Need to Know

    Managed and Unmanaged packages in Salesforce in 2023 | All You Need to Know

    What are the various types of packages in Salesforce? Let’s understand!

    Unmanaged Package

    Think of it as a beautifully wrapped gift box that you can open and see what’s inside. It’s free, the code is visible and you can even move the components from the existing org to any other org even if it’s not related to each other. But on the other hand, it cannot be upgraded once a new version is released and hence you may have to re-install the same in the new org.  

    Managed Package

    A Salesforce managed package has its code hidden and it is introduced to the AppExchange marketplace as a single entity. More like any other app out there, the end user gets all the benefits of the product but does not have access to the code base. Managed packages are commonly preferred among Salesforce partners to distribute and sell applications on AppExchange due to their protected nature. It can be easily upgraded like your operating system and it automatically updates the code. 

    There are three versions of managed packages 

    • Managed – Beta: A version of the managed package for testing apps 
    • Managed – Released:  The package is launched on AppExchange and  is publicly available 
    • Managed – Installed: Package is installed from another Salesforce org, but managed 

    Benefits of Managed packaging 

    • Full API access for all editions. 
    • API-accessible components have integrated versioning support. 
    • Automatic upgrades are available. 
    • Customers can easily access applications from AppExchange.  
    • You can branch and patch a previous version. 
    • You can seamlessly provide subscribers with patch updates. 

    dont miss out iconDon’t forget to check out: Why Use Second-Generation Packages in Salesforce?

    Key Differences between Managed and Unmanaged Packaging

    Managed Packages  Unmanaged Packages 
    Easily Customizable and upgradable   Cannot be upgraded and only be customized/ edited in the org they have been installed. 
    Highly protected and secure from data threats  High risk for data loss due to lack of review 
    It is used to distribute open-source projects or application templates to developers  It is used by Salesforce partners to sell and distribute applications via AppExchange 
    It does not count against the total limit of your Salesforce org for tabs and custom objects.  It does count against the total limit of your Salesforce org for tabs and custom objects. 

    When to go with  Managed or Unmanaged packaging?

    On first look, unmanaged packages are great as it’s free, and faster to launch. However, these are best recommended if you are providing a highly customized piece of code for a select few of your high-priority customers. Scalability will be an issue here. 

    Managed packages on the contrary are the go-to approach if you are looking to tap into the Salesforce ecosystem as a growth stream for your product. It’s scalable, carries the badge of trust having undergone the Salesforce security review and is backed by robust tools to manage the features of your app. 

    dont miss out iconCheck out anther amazing blog by Navdita here: What are Rendered, Rerender, RenderAs Attributes? | Salesforce Guide

    Having an experienced partner in the development of a managed package is critical for your product’s success in the AppExchange space. We have a solid track record of enabling product managers and CEOs of product companies to launch, grow and thrive in AppExchange.  

  • What are Managed & Unmanaged Packages in Salesforce in 2023?

    What are Managed & Unmanaged Packages in Salesforce in 2023?

    Salesforce is one of the most widely used Customer Relationship Management (CRM) tools in the world. It provides a platform for organizations to build, customize, and deploy applications on the cloud. Salesforce offers a wide range of features and functionalities that can be customized according to the specific needs of an organization. One such feature is the packaging.

    Packaging is a process of bundling components such as code, metadata, and other related resources into a single container. It allows developers to distribute their applications and components as a single entity. Salesforce provides two types of packaging: managed and unmanaged.

    Managed Packages

    Managed packages are a way to distribute and sell custom applications and components on the Salesforce AppExchange. They are designed to be sold or distributed as a complete application, and once installed, they can be upgraded or uninstalled by the developer who created them. Managed packages provide the following benefits:

    1. Protection of Intellectual Property: Managed packages provide a high degree of intellectual property protection. Once a managed package is installed, the components in the package cannot be edited or deleted by the user. This ensures that the developer’s code and customizations are protected.
    2. Version Control: Managed packages provide version control, allowing developers to create different versions of their packages. This enables them to offer updates and bug fixes to their users.
    3. Upgradeability: Managed packages can be upgraded or uninstalled by the developer who created them. This ensures that the application remains up-to-date and relevant.
    4. License Management: Managed packages can be licensed and sold on the Salesforce AppExchange. This enables developers to monetize their applications and components.

    dont miss out iconDon’t forget to check out: Resolution of Managed Packages – Salesforce DX Developer Guide

    Unmanaged Packages

    Unmanaged packages are designed to be used in development and testing environments. They are not intended to be distributed or sold on the Salesforce AppExchange. Unmanaged packages provide the following benefits:

    1. Flexibility: Unmanaged packages provide a high degree of flexibility, as the components in the package can be edited or deleted by the user. This allows developers to make changes to their code and customizations as needed.
    2. Ease of Deployment: Unmanaged packages can be deployed quickly and easily between different Salesforce organizations.
    3. Testing: Unmanaged packages are useful for testing purposes, as they allow developers to test their code and customizations in a controlled environment.
    4. Free: Unmanaged packages are free to use, making them a cost-effective solution for development and testing purposes.

    dont miss out iconCheck out another amazing blog by Mohit here: The Most Important Pardot Automation Rules You Need to Know in 2023

    Conclusion

    In conclusion, managed and unmanaged packages are both valuable tools in the Salesforce development process. Managed packages provide protection of intellectual property, version control, upgradeability, and license management, while unmanaged packages provide flexibility, ease of deployment, and testing, and are free to use. The choice of which package to use depends on the intended use case, whether for commercial purposes or development and testing purposes. It is important for developers to carefully consider their requirements and choose the appropriate packaging type accordingly.

  • Why Use Second-Generation Packages in Salesforce?

    Why Use Second-Generation Packages in Salesforce?

    Do you know about Second-Generation packages?

    Max Shkrob, Salesforce Developer at Twistellar, gathered all the features and the main differences between 1GP and 2GP. Happy to share knowledge with our code experts. Look!

    ❛ Hello everyone! A short time ago, I found something new for myself in SF Packages and decided to share a short article about it. I hope it will be helpful for you! ❜

    Okay, so what are Second-Generation Packages in Salesforce? 2GP is a new way to build packages in Salesforce using SFDX and version control. It allows building your packages in a more “dev” way than the first generation. Let me show you below the main differences between 1GP and 2GP.

    1. Org vs. Version Control System

    In 1GP, a packaging org is the source of truth for the metadata in your package. This means that your org controls what you include in your package. In 2GP, your version control system becomes the source of truth for the metadata in your package. It allows you to select what metadata should be included in your package.

    Why do we need this? Let’s imagine that you have complex logic and to test it, you created some classes and components that have dependencies with the metadata that you want to include in the package. To build 1GP, you will need to delete the metadata from the org that you don’t want to include. In 2GP, just don’t include it in your version control that’s all. All that you don’t want to include may still be in your org.

    2. Number of Managed Packages

    1GP: a packaging org can own only one managed package. 2GP: The namespace of a managed package is created in a namespace org and linked to the Dev Hub. It means that in 2GP, you can create more than one managed package in one org and select the metadata to be included in that package using SFDX. Cool, right? ?

    Okay, so we can create more than one package in one org. But what do namespace org and linked Dev Hub stand for?

    To make a 2GP, you will need to:

    • Create a Dev Org and create a namespace (as in 1GP)
    • Create and log in to the Dev Hub org you created to make packages, then add permission to your System Administrator to register a namespace (SalesforceDX Namespace Registry checkbox)
    • Then go to App Launcher and type in Namespace Registries. Open and click on Link Namespace. It will ask you to log in to your Dev Org with a namespace and give access to use the namespace
    • That’s it. Now you have a Dev Hub ready to build your packages.

    Note 1: You can link more than one Dev Hub to an org with the same namespace, but SF recommends using one Dev Hub for one org with a namespace.

    Note 2: As per Note 1, I tried to create two packages using different Dev Hubs and one namespace with Apex class having one class with the same name in both packages. I received an error when trying to deploy the second package in an org where the first one was already installed. So if you decide to use more than one Dev Hub, please be ready to resolve such issues.

    dont miss out iconDon’t forget to check out: Salesforce Apps: Managed vs. UnManaged Package Importance from Lederhosen Salesforce

    3. Global Apex vs. @namespaceAccessible Annotation

    Now you know that you can create multiple packages with the same name, but is it possible to make them communicate together? And the answer is yes! In 1GP, the only way to use methods from one class from one package in other classes of the second package is through Global Apex, but in 2GP you can use the @namespaceAccessible annotation.

    @namespaceAccessible allows packages with the same namespaces to use each other’s methods in an org where they are installed. It still makes them secure and allows you to build big products from more than one package.

    Notes: Here’s something you need to know about @namespaceAccessible.

    • You can’t use the @namespaceAccessible annotation for an @AuraEnabled Apex method.
    • You can add or remove the @namespaceAccessible annotation at any time, even on managed and released Apex code.
    • If a public or protected variable or method is declared as @namespaceAccessible, its defining class must be either global or public with the @namespaceAccessible annotation.
    Apex method

    4. Package Versioning

    1GP: Package versioning is linear, and patch versions can only be created in specialized orgs called patch orgs. 2GP: Package versioning supports branches and patch versions are created using Salesforce CLI. The version control system is the source of truth, and there are no patch orgs.

    Because 2GP uses version control, you can use not only a linear way to build package versions, but also the one resembling a “tree” in VCS.

    Package Versioning

    You can read more about how versions work in 2GP here: Patch Versions and Package Ancestors

    5. Unlocked Packages

    One more thing that 2GP has and 1GP doesn’t, are unlocked packages. Unlocked packages are something between Managed and Unmanaged packages.

    • They can be created with or without a namespace
    • CLI is mandatory to create an unlocked package
    • Not IP protected. It can be edited in the installed org. Thus, it gives users who have installed the package the ability to change its code but be careful with this, because if you create a new version of a package and users update their organization with that version, they will overwrite their changes with the changes from the new version.

    dont miss out iconCheck out another amazing log by Twistellar here: How to Send SMS Messages from Salesforce That Really Work

    To Wrap It Up

    These were some key features of Second-Generation Packages and my thoughts on why you can use them instead of Fist-Generation Packages. Here are the links that will help you start building 2GP packages: Workflow for 2GP and Package Commands.

    I hope this article will help you, good luck and happy coding!

    ?Subscribe to our blog to get the latest Salesforce expert articles.

    Follow Twistellar’s page on LinkedIn or subscribe to our blog to get more materials.