We have an aura component implemented as below.


<aura:component controller ="MyController">
<aura:handler name="init" value="{!this}" action="{!c.doInit}"/>


// in doInit
var action = component.get("c.getCustomMetadata1");


public static List<MyWrapperClass> getCustomMetadata1() {
    // SOQL to fetch CustomMetadata1__mdt
    // return a list of wrapper class

public static List<CustomMetadata2__mdt> getCustomMetadata2() {
    // SOQL to fetch CustomMetadata2
    // return list of CustomMetadata2 

This implementation works fine on Winter '20 sandbox but started breaking on Spring '20 preview sandbox specifically on getCustomMetadata2() method.

On Spring '20 preview, even if the component did not refer to this method during its initialization (this method was never referenced on init at all), just having the class name in controller caused the component to fail and not render with an error message as:

$A.getCallback() Invalid definition for null:MyController: Access to entity 'CustomMetadata2__mdt' denied. Entity not readable

This was though intermittent and not for all Users.

Upon investigation we found that the issue was caused because of the critical update Require Customize Application Permission for Direct Read Access to Custom Metadata Types (Critical Update).

As the release notes mentions:

This critical update is enforced in the Spring ’20 release

This update was already enforced and thus was causing the issue on the Spring '20 preview sandboxes but is not activated on Winter '20 and thus it works fine there.

So as noted in the release notes, once we assigned the CustomMetadata2__mdt to respective profile, things were working as expected.

However the release notes also says:

This change doesn’t affect accessibility of custom metadata types from Apex or system mode contexts. Custom metadata types retrieved using your custom Apex code continue to work after this update.

But what we observed was that it works if the return type in the method is not of Custom Metadata but any other type (as it is for getCustomMetadata1()). As soon as we have a return type referring the Custom Metadata directly, the component fails to render right away (as we observed for getCustomMetadata2()).

Now we have two versions of this:

  1. CustomMetadata1__mdt is not assigned to the Profile, but is still being referred in Apex method but return type is a wrapper class - this works fine
  2. CustomMetadata2__mdt is returned directly in second Apex method - this fails and only works if it is assigned for access on Profile

Additionally the Setup --> Schema settings is enabled for metadata access in Apex.


We are also reaching out to Support to get more information on this

But in the meantime wanted to see if anyone has observed this specific behavior? I am still wondering why one version will work vs. not the other when release notes specifies it should work in Apex. Does this mean that we cannot have a Custom Metadata in return type without that metadata access assigned on Profile?

  • 1
    When you use the wrapper, you made sure to mark the custom metadata type property as @AuraEnabled right? Just covering bases. Also, I haven't found any info, but I wonder if Spring 20 has introduced a configuration or permission option that makes custom metadata types not exposed via AuraEnabled methods by default. Some critical updates you might look at here: releasenotes.docs.salesforce.com/en-us/winter20/release-notes/…
    – nbrown
    Jan 7, 2020 at 22:53
  • 1
    @nbrown We don't have any issue on the wrapper approach and things are fine there. We fetch the metadata and then assign it to the wrapper properties which we then access on the component - all good there. I doubt the same as you have mentioned that if custom metadata cannot be exposed directly via AuraEnabled methods.
    – Jayant Das
    Jan 7, 2020 at 23:29

2 Answers 2


This is anticipated behavior - from the release note

This change affects Visualforce pages and Lightning components that directly reference custom metadata types.

You can see a related known issue for a visualforce scenario where the recommended workaround is indeed to use a wrapper class.

I'm on the team that builds custom metadata, I will work with our doc writer to see how we can clarify this.

Specifically to answer your question:

Does this mean that we cannot have a Custom Metadata in return type without that metadata access assigned on Profile?

Yes, the return value of the AuraEnabled method must be a type that the user has access to (or be a custom apex type).

  • Thanks for confirming this. The doc is confusing for sure. At one point it mentions what you have quoted and then later in the same doc it mentions there is no impact if used in Apex (the one I quoted in the question).
    – Jayant Das
    Jan 16, 2020 at 17:04
  • I also wanted to add a note here that this behavior does not seem to be consistent. In one of our other sandboxes, this worked without the metadata assigned to the profile. Interestingly while replicating this with support, it worked seamlessly without the need of assigning the metadata in the sandbox that we were facing the issue with. I am just not sure if there was a patch released recently that would have caused this.
    – Jayant Das
    Jan 16, 2020 at 17:56
  • @JayantDas - can you share your case number? feel free to email at firstname.lastname @ salesforce dot com. Jan 20, 2020 at 21:47
  • This is the case# 25289425. At this point of time we are not really sure if we need to assign the custom metadata to profile or not, as it works without the custom metadata being assigned to profile.
    – Jayant Das
    Jan 21, 2020 at 13:09

This issue seemed to be intermittent at the time we first observed this and was never reproducible later.

After keeping the case (#25289425) that we had opened with Support for sometime and that neither the Support nor us were able to replicate the issue after a certain period of time, we concluded that there is no requirement to assign the custom metadata on profile as long as that's accessed through Apex class as mentioned in the release notes:

This change doesn’t affect accessibility of custom metadata types from Apex or system mode contexts. Custom metadata types retrieved using your custom Apex code continue to work after this update.

It just seems that this was broken at one point of time because of the fact we observed this and then later possibly resolved with some patch or other which we were never able to identify!

  • Our users have been experiencing this intermittently in our Production org since at least Feb. 19th. It's not regularly reproducible and seems to occur haphazardly. The custom metadata type is being accessed via an AuraEnabled Apex method. Once they cancel out of the AuraHandledExceptions, they're able to reload the page without errors. I'll be filing a case for this, because we would prefer not to have to assign the custom metadata by profiles if not 100% necessary (more configuration to keep track of, that isn't available to configure via the metadata API.)
    – Delphine
    Feb 26, 2020 at 1:21
  • We had in lower environments resolved this by assigning the metadata to profile (which I never wanted and based on docs doesn’t seem to be necessary either). We did file a case but the support was never able to reproduce the error. Also we ended up removing it from profile and that’s how it’s currently in production with no errors (fingers crossed!)
    – Jayant Das
    Feb 26, 2020 at 1:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .