Packages: Admin-Friendly Way to Move Metadata to Another Org

I build cool shit in Salesforce that I want to share with other people. How do I do that quickly and easily? I make an unmanaged package.

• From Setup, search for and go to Package Manager.
• Click New.
• Fill out the form. Give yourself credit for creating the package and a way to get more information in applicable.
• Don’t check “Managed.” By leaving it unchecked, you allow people who install it to make their own modifications.

• Add components to your flow. Click Add.
• Select your component type in the picklist. If you’re including a process from Process Builder, use Flow Definition.

• If your flow, process, code, formula, references custom fields, objects, etc., the package will automatically pull those in to the package. I added one flow and it pulled all of these things in! That’s really helpful.
• You can include permission sets to allow certain users to access what’s in your package.

• I frequently build things that require Nonprofit Success Pack to work. The package will list those components in the package, and when you go to install it, it will not install if NPSP isn’t already installed. But it won’t install them again as part of the package.
• When I’m done adding things, I click Upload.
• The version name doesn’t matter a whole lot. (I started naming my last Unsubscribe Link package after what day of Christmas it was according to the 12 Days of Christmas).
• Do you have release notes or a place for folks to go for post-install instructions? Great! Add in those URLs.
• Put in another description. I guess this describes the version rather than the package overall.
• I ignore everything else on the page! What’s all that stuff? Don’t care!
• Click Upload.

• Now you have a URL to share with your friends or another production org. BUT WAIT. It doesn’t actually work yet. If you click on it now, you’ll probably get an error that it takes a few minutes.

The URL

Here’s the URL I got:

https://login.salesforce.com/packaging/installPackage.apexp?p0=04t2T000000gYzH

This will take me to the log-in page of Salesforce, then to the installation page. You may recognize this from installing apps from AppExchange.

• If I want to install it in a sandbox, I change “login” to “test” https://test.salesforce.com/packaging/installPackage.apexp?p0=04t2T000000gYzH
• If I am already logged into the org I want to install the package in, I copy everything in the URL after .com /packaging/installPackage.apexp?p0=04t2T000000gYzH
  • In my browser, on a tab that of the org I want to install in, I remove everything after .com in the URL. So if I’m logged in here https://bigbootycom-dev-ed.lightning.force.com/lightning/setup/Package/04t4W000002g2Rw/view that becomes https://bigbootycom-dev-ed.lightning.force.com/ and then I paste in packaging/installPackage.apexp?p0=04t2T000000gYzM so I go to https://bigbootycom-dev-ed.lightning.force.com/packaging/installPackage.apexp?p0=04t2T000000gYzM and I end up directly at the installation page.

Testing

Test out your package in an org. If it doesn’t work, or you need to make a change, you can modify your package by finding it under Installed Packages in the org you created it in. You’ll need to upload again and you can come up with another version name. It usually takes me a few tries to get it right.

Benefits

There are many ways to move metadata between orgs and developers can name a bunch! I’m still learning dev tools for this. I should be fully competent by the end of the year as this is a major part of my new job. And I can follow up with what I learn.

This isn’t a substitute for change sets. It’s more of a way to move stuff to an unrelated org.

Now, if you have cool things you want to share but aren’t sure where to share them… you want to share them here? Happy to share on the blog! Contact me.