Has anyone encountered this problem when evaluating $Setup global variable in Visualforce?

If, in an organization with a namespace prefix, I have a hierarchy Custom Setting like the following, it compiles and renders without exception, except that the output value is null

<!-- evaluates and outputs null -->

Now if I want the custom setting to resolve correctly, I have to fully qualify the Object Name and Field Name, and I believe this is new behaviour:

<!-- evaluates and outputs actual intended value -->

This means you can no longer use the same codebase in Development and Release environments... you would need to tokenize/replace the namespace prefix when deploying to the appropriate variant.

I've tried dynamically dereferencing the field: $Setup['Object__c']['Field__c'] to no avail.

Any ideas what causes this regression and how we fix it?


The issue your facing seems to be related to the following known issue which will be fixed in winter 15 release. https://success.salesforce.com/issues_view?id=a1p30000000T5P9AAK

  • I've deployed the codebase in question to a Winter '15 prerelease org and verified it does fix the need to overqualify those references. Thanks very much for contributing here. – bigassforce Sep 22 '14 at 23:58
  • 1
    Is this actually fixed? I seems to be broken in Spring '17. I'm getting default values back unless the namespace is explicitly included. – Daniel Ballinger Mar 1 '17 at 1:22
  • @DanielBallinger - Were you able to get a resolution on this? it doesn't seem to work for us as well, without hard namespace references. – VarunC Feb 17 at 7:16
  • @VarunC I'm using the fully qualified namespace on all the custom setting $Setup references. It may or may not be required, but with scratch orgs connected to a devhub where the namespace is registered it isn't an issue for me currently. That is to say, scratch orgs allowed me to work around the issue entirely, so I haven't really followed up on it. – Daniel Ballinger Feb 17 at 19:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.