Step by Step Guide to Deploying using Unmanaged Package in Salesforce

How to deploy metadata components between unrelated Salesforce Orgs

Unmanaged Package in Salesforce

If you are familiar with change sets in Salesforce, you know that it can be used to transfer metadata between related orgs. For example, transfer the objects, fields, apex classes, etc. from sandbox to production, production to sandbox, and sandbox to sandbox. 

But what if you need to transfer metadata between unrelated orgs or completely different orgs? There are a couple of options, one of which is the ANT Migration Tool provided by Salesforce. (If you are not yet familiar with ANT Migration Tool, you may want to make a note to refer to my another blog post 
Step-by-Step Guide on Getting Started with Salesforce ANT Migration Tool)

The other option for moving metadata from one org to another org is using Packages. 

A package in Salesforce refers to a container. You can use this container to add the metadata/components from a source org that you wish to transfer/distribute to another org i.e. Target Org. Packages come in two flavors.

  1. Unmanaged Package
  2. Managed Package
Unmanaged Package

Unmanaged Packages in Salesforce can be used to move a set of metadata from one org (source) to another org (target) even if they are completely unrelated. Unmanaged packages are usually used for distributing open-source projects, an application template, or foundational work. Once installed in the target org, you can then build upon it. 

For an Unmanaged Package in Salesforce, the package creator does not have control over the components of the package. Once the package is installed, the installers can modify the components. You can’t provide an upgrade either. In a developer edition or Trailhead playground, you can create only unmanaged packages.  

Managed Package

Managed package, on the other hand, is used to sell applications and to distribute on AppExchange. In these types, the creator does have control over the application and can release upgrades. The creator can control the usage with user-based paid licenses. There are special developer editions to create Managed Packages.  

Now that you have a basic understanding of what an Unmanaged Package is, let’s get hands-on experience in creating an Unmanaged Package in Salesforce within just 15-20 minutes. This step by step guide covers how to:

  • Create an Unmanaged Package
  • Add Components
  • Upload the Package
  • Install the Package in Target Org
  • Verify Installed Package
  • Deprecate the Package

References & Useful URLs

5 thoughts on “Step by Step Guide to Deploying using Unmanaged Package in Salesforce”

  1. while uploading its giving me error of weblink related to a custom object report. i am trying to figure it out but its not helping. The mentioned report is there in org too. Can you help me in this.

    1. Hi Hazma, are there any error messages or error screenshots that you can share? Please also make sure that the custom object, fields and everything required for the report are a part of the unmanaged package.

    1. Yes Saritha, you need test classes whenever you want to deploy to production. Without test classes, you won’t be able to deploy to production at all even if they are getting deployed through unmanaged package.

  2. Great article. ANT migration tools generally required technical orientation so the unmanaged package provides a great point and click alternative.

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top

Don't Miss Out on New Step-by-Step How To Guides on Salesforce...

…Subscribe to Our Newsletter!