Erfassen Sie Ihre Fortschritte

Protect Custom Metadata Types and Records

Learning Objectives

After completing this unit, you’ll be able to:
  • Identify the options for protecting custom metadata types.
  • Control the editability of a field.
  • Protect custom metadata records.

Protect Custom Metadata Types

With custom metadata types and records, you can determine who can access and change the types and records you created. When you create a type, you can choose whether the type is public or protected. All Apex code in an org can use public types. Only code within the package can use protected types.

That’s simple. It gets a little more complicated when we talk about controlling edit access to custom metadata fields and records.

Protect Custom Metadata Records

Instead of protecting an entire metadata type, you can protect individual records within a public type. If a developer releases protected records in a managed package, access to them is limited in specific ways.
  • Code that’s in the same namespace as custom metadata records can read the records.
  • Code that’s in the same namespace as custom metadata types can read the records that belong to that type.
  • Code that’s in a namespace that doesn’t contain either the type or the protected record can’t read the protected records.
  • Code that the subscriber creates and code that’s in an unmanaged package can’t read the protected records.
You can also protect custom metadata types, providing the same access protection as protected records. If you change a type from protected to public, its protected records remain protected, and all other records become public. If you use Setup to create a record on a protected type, Protected Component is selected by default.

When a type is public, you can’t convert it to protected. The subscriber can’t create records of a protected type.

Field Manageability

When it comes to protecting fields on custom metadata types, you have three options.
  • The package developer can use package upgrades to edit the field after release. Subscriber orgs can’t change the field.
  • The subscriber org can edit the field after installing the package. Package upgrades don’t override the subscriber’s changes.
  • Neither the package developer nor the subscriber can edit the field after the package is released.
These options seem fairly simple, but let’s take some time to dig in to how everything works together.

Put It All Together

Let’s say we’re putting our Support Tier type in a managed package. For legal reasons, we don’t want package subscribers to change the Default Discount field. As the package developer, you still want to be able to change it in later package releases if the legal requirements change. So, you want the Default Discount field to be upgradeable.

The values on the Minimum Spending field vary depending on the org, though. Sometimes orgs change the minimum spending amounts based on local factors. To account for this need, make the Minimum Spending field subscriber editable.

Review this table to see who can edit the fields on both public and protected records in a managed package.
Developer Name Label Support Tier (upgradeable) Support Level Mapping (subscriber editable)
Public record Developer Developer Subscriber
Protected record Developer Developer
In a managed package, the package developer can always edit upgradeable fields. Subscribers can edit subscriber editable fields on public records but not on protected records. Subscriber editable fields on protected records are locked after release.

If we look at the same custom metadata type and its associated records in an unmanaged package, it’s easier to see who can edit what.

Developer Name Label Support Tier (upgradeable) Support Level Mapping (subscriber editable)
Public record Subscriber Subscriber Subscriber Subscriber
Protected record Subscriber Subscriber Subscriber Subscriber

An unmanaged package gives the subscriber freedom to edit records and fields on custom metadata types.

The moral of this unit is that field management can get complicated quickly. It’s important to plan how you want to manage your custom metadata types, fields, and records before you package your app and release it into the wild.
When you want Use
Subscribers to be able to change anything within the metadata type. For example, your subscribers must add more custom fields to your type. Public type
Subscribers to use your metadata type but not make changes. For example, you might want to make the Support Tier custom metadata type available to all Acme subsidiaries, but you want the records to remain as they are. Protected type
A subscriber org or extension package to add its own records to the type. (A protected record is only accessible to code in the same namespace as the record or its associated custom metadata type.) For example, perhaps you want subsidiaries at Acme to be able to add another tier record, such as Platinum. Public type with protected records
Speaking of packaging, we’ll start that adventure next!