Custom Metadata Types Limitations

Updating Types and Records

If your Apex code is in the same namespace as either protected metadata types or their records, you can update the types and records in an installed managed package programmatically.

To modify records from Apex, you must use the Metadata package in Apex.

If you delete a protected custom metadata type record that was part of a released package, you can't create another record with that name again.

Application Lifecycle Management Tools

Custom metadata types don’t support these application lifecycle management tools:

• Tooling API
• Developer Console

Licenses

Licenses that are defined for an extension package aren’t enforced on custom metadata records in that package unless the types are also in the package.

SOQL

Custom metadata types support the following SOQL query syntax.

SELECT fieldList [...]
FROM objectType
    [USING SCOPE filterScope]
[WHERE conditionExpression]
[ORDER BY field {ASC|DESC} [NULLS {FIRST|LAST}] ]

• You can use metadata relationship fields in the fieldList and conditionExpression.
• FROM can include only 1 object.
• You can use these operators.
  • IN and NOT IN
  • =, >, >=, <, <=, and !=
  • LIKE, including wild cards
  • AND
  • OR when on the same column with LIKE and = operations
    

    Note OR can’t be used as a compound filter when child filters are on two different columns.
• You can use ORDER BY only with non-relationship fields.
• You can use ORDER BY, ASC, and DESC with multiple (non-relationship) fields.
• Metadata relationship fields support all standard relationship queries.

Protected Custom Metadata Types

Subscribers can’t add custom metadata records to installed custom metadata types that are protected. To allow subscribers to create custom metadata records, the custom metadata type must be public.

Metadata API returns protected custom entity definitions (but not custom metadata records) in subscriber orgs.

Caching

Custom metadata records are cached at the type level after the first read request. Caching enhances performance on subsequent requests. Requests that are in flight when metadata is updated don’t get the most recent metadata.

Global Picklists

Global picklists aren’t supported on custom metadata types. You can only use sObject picklists.

Picklists and Managed Packages

• You can add a custom metadata type that has a picklist field with inactive values to a managed package, but you can’t upload the package. To upload the package, delete or reactivate the picklist values.
• Subscribers to a released managed package that contains a custom metadata type with a picklist field can’t add, delete, or deactivate values from that picklist.
• Developers who release a managed package that contains a custom metadata type with a picklist field can add picklist values but not delete or deactivate them.

Custom Metadata Type Records and Managed Packages

• After you remove the records from a package, if those records are visible to the subscriber org, they’re marked as deprecated. If the records aren’t visible to the subscriber org, they’re deleted.
• Deprecated records in a subscriber org count towards that org’s custom metadata limits. When a subscriber org reaches its custom metadata record limit, future package installs or upgrades could be blocked until deprecated records are deleted by the subscriber.

Shield Platform Encryption

Custom metadata types don’t support Shield Platform Encryption for fields.

Validation Rules

• You can reference up to 15 unique custom metadata types in all validation rules per entity. For example, from all validation rule formulas combined for a specified object, you can reference up to 15 different custom metadata types. However, you can include more than 15 references to the same custom metadata type in your validation rules.
• During deployment, custom metadata records that are included in the package are locked to maintain referential integrity. Other processes must wait until the deployment completes and the records are no longer locked before the same records can be updated. Validation rules that read custom metadata types can also create locks. For example, validation rule formulas that reference a custom metadata type record can create a read lock on the record. Because of the locks created during deployment, row lock errors can occur. If you encounter row locks, Salesforce recommends deploying during off-peak hours.

Formula Fields

• Spanning custom metadata type relationships isn’t supported in formula fields. Use Apex to avoid spanning relationships.
• Formulas that reference custom metadata types aren’t supported in approval processes. For example, if you define a formula field that references a custom metadata type, you can’t use that field in an approval process. Similarly, if you try to update an existing formula field to reference a custom metadata type, but that field is already used in an active or inactive approval process, you can’t save the formula.

Formulas on Actions

Custom metadata types are supported in only a few formula contexts, such as those for validation rules, default values on custom fields, custom formula fields, and formulas in Process Builder. However, custom metadata types aren’t supported in predefined value formulas on actions.

Permission Set Muting

Custom metadata types don’t support permission set muting.

Workflow Rules

Custom metadata types that contain fields that are associated with workflow field updates aren’t supported.

Flows

Flow bulkification is automatically disabled under specific conditions when using a Get Records element to query a custom metadata type, falling back to a non-bulkified path.

This behavior prevents a MALFORMED_QUERY exception because of SOQL limitations. It occurs when the Get Records filter uses an AND filter on a custom metadata type, and the filter conditions reference values such as $Record.field that vary across the bulk transaction. The flow attempts to bulkify this query by internally adding OR logic to the existing AND filters. Queries on custom metadata types don't support combining AND and OR across different fields. The flow automatically falls back to a non-bulkified path to avoid failure.

The non-bulkified path causes you to exceed governor limits when processing large batches. Consider these alternatives:

• Switch to Apex: Querying custom metadata records using SOQL in Apex code doesn't count toward standard SOQL row limits.
• Modify flow filter: Avoid using formulas such as $Record.field in the filter condition if those values vary across the bulk transaction. Use a static filter or one that evaluates to the same value for all records.