Background: We develop a managed package and are auditing the code for hardcoded references to the namespace. We want to use static/resolved references of objects/fields/pages/custom settings instead of the hardcoded namespace strings in order to support a multi-org/developer lifecycle.

I'm having trouble finding an alternative to referencing a hierarchy custom settings in a VF page without having to use the namespace for the field name.


Custom Settings (type = hierarchy): System_Preferences__c
Field Name: Default_Email__c
Namespace: abc

//within javascript

var defaultEmail = '{!$Setup.System_Preferences__c.abc__Default_Email__c}';  // works

var defaultEmail = '{!$Setup.System_Preferences__c.Default_Email__c}';  // returns null

Is there another way to do this? Or is this a current limitation?




When I was working on a managed package, we always had to use an apex:outputText element to get the correct value to merge. Try this:

var defaultEmail = '<apex:outputText value="{!JSENCODE($Setup.System_Preferences__c.Default_Email__c)}" />';

Not only does this pattern avoid migration problems, but also the occasional installation/execution problem in installed orgs.

Besides that clunky solution, you could also just grab the value in an extension or controller and emit it directly.

  • The clunky solution meets my needs! I have more than 5 properties that I would be referencing on various custom settings, so the extension route would get tedious. Thanks! – Brian Dunzweiler Aug 13 '14 at 16:56

It's not perfect but we have used $Organization.Name before.

Basically we'd set the org. name in the package, source & related sandboxes / dev. orgs to specific values and then check for the presence of any of those vales in $Organization.Name. If present, don't use a namespace.

I'm sure I came up with a more elegant solution before but I can't for the life of me remember what is was right now.

  • Did you use a build script to swap out the code based on the environment? I've seen posts/comments of teams doing something similar. – Brian Dunzweiler Aug 12 '14 at 15:06
  • No, we've left that logic permanently in place so that the functionality always work regardless of whether it's a fresh client install or a newly spun up source sandbox. – Davin Casey Aug 12 '14 at 15:22
  • Hmm, then I'm not sure I understand how your suggestion gets around the issue. If I try to deploy the raw code in a different org than the packaging org, it won't compile due to the namespace reference. – Brian Dunzweiler Aug 12 '14 at 15:39

I had the same scenario but I found another way to do it. First I identified the namespace which will be based on the org. If it's dev org then namespace will be blank but for the subscriber or package org it will be there. This part was done in the controller.

So once you found the namespace then it's quite easy to get the custom setting values.

{!$Setup[namespace + 'Custom_Setting_API_Name__c'][namespace + 'Field_API_Name__c']}

For the namespace, you just need to find whether your code is executing in the managed package or not. I did it using a code snippet in the controller.

public String getNamespace() { 

    String nameSpacePrefix;
    ApexClass cs =[select NamespacePrefix from ApexClass where Name ='NamespaceDemoCompController'];
    if(cs.NamespacePrefix != null){
        nameSpacePrefix = cs.NamespacePrefix+'__';
        nameSpacePrefix = '';

    return nameSpacePrefix;

For more details, please check my blog - https://sfcure.com/2018/01/22/salesforce-cookies-8/

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.