Package Custom Metadata Types
Learning Objectives
- Package your custom metadata types.
- Package your types’ associated records.
- Upload your package.
- Install your package in a subscriber org.
- Upgrade your package.
Package Custom Metadata Types
When you’re ready to package up your custom metadata types and records, you can choose your own adventure. Managed packages, unmanaged packages, and managed package extensions are all compatible with custom metadata types. And change sets let you deploy your types and records from a sandbox.
You’re itching to get your Support Tier type out to your other orgs, so let’s do it.
- From Setup, search for Package Manager and then click a package name (or create a package if you haven’t yet). You can use either a managed package or an unmanaged package. You can have only one managed package per Developer Edition org. To create a managed package, your org must be namespaced. If you aren’t familiar with namespaces or don’t want to add a namespace, use an unmanaged package.
Next, you add your custom metadata type to the package. - Click Add.
- For the component type, select Custom Metadata Type.
- Select Support Tier.
- Click Add to Package.
Easy! Notice that your custom metadata type and its fields were added to the package, but your records are missing. Let’s take care of that next.
Package Custom Metadata Records
Adding custom metadata records to a package follows the same process as adding custom metadata types to a package, with one difference. Instead of selecting a standard option from the list of component types, you select your specific type. Let’s give it a try, starting from the package detail page.
- Click Add.
- For the component type, select Support Tier.
- Select all your custom metadata records.
- Click Add to Package.
Whenever you add custom metadata type records to a package, the custom metadata type is added to the package automatically.
Upload Packages
After you’ve added all your custom metadata types, records, and any other components your app needs, you’re ready to rock and roll. Uploading a package that contains custom metadata types and records isn’t any different from uploading other types of packages.
- Click Upload on the package detail page to kick off the process.
- Set the version name to Fall 2019.
- Leave the Version Number as is. Typically if you’re using a managed package, you want your first release to be beta. But we’re all about diving in, so let’s go straight for the big time.
- Select Managed - Released for the release type. If you’re using an unmanaged package, don’t worry about this part. For more complex packages, you probably have to spend some time fiddling with the other options on this page.
- Click Upload and wait for the process to complete.
Install Packages
When your upload is finished, you receive an email with an installation link for your package.
- Make sure that you’re logged out of the org where you developed the package.
- Follow the link in the email, and log in to your alternate account.
- When prompted, install the package for admins only. When the installation completes, your app appears on the Installed Packages page.
But how do you know whether you successfully completed your journey?
In the Quick Find box, search for Custom Metadata Types. If all went as planned, you see your Support Tier custom metadata type. That’s all well and good, but what you’re interested in is whether your records migrated over.
Click Manage Records.
Looks like the gang’s all here! You’ve successfully moved your app configuration records from one org to another in just a few easy steps.
Upgrade Packages with Custom Metadata Types
App development is rarely a one-and-done process. Down the line, you’ll want to make improvements and fix your app.
Upgrading managed packages is where our earlier discussion about field manageability is especially important.
Because the Default Discount field is upgradeable, the package developer can change the Default Discount field and the values of the Default Discount field on records in future iterations of the app. Subscriber orgs, however, can’t make changes. They can create Support Tier records, but cannot edit existing records.
Minimum Spending is a subscriber editable field, so the subscriber org can change the field based on its own needs. Subscriber editable also means that you can’t overwrite your subscriber’s values through a package upgrade.
If you created a managed package, you can deploy an upgrade to see how this works.
- In your development org, make changes to both the Default Discount and Minimum Spending fields.
- Using the same process as before, upload your package and use the email link to reinstall it in your subscriber org.
- Check the fields and records on the upgraded package. You can see the changes that you made to the Default Discount field, but the Minimum Spending field looks the same as it did before the upgrade.
