1. Managed Package
  2. Class is global class
  3. Field Named NS__Field_Name__c
  4. Running in subscriber org code:

      String fld = 'NS_Field_Name__c'; 
      Map<String,sobjectField> flds = object__c.sobjecttype.getDescribe().fields.getMap();
      Boolean test1 = flds.containsKey(fld);
      Boolean test2 = flds.containsKey(fld.replace('NS__',''));

In the above the result of

test1 = FALSE

test2 = TRUE

What is going on??? Why do I have to remove the namespace for the field to be found? When doing merge fields etc the name space MUST be included.....

Yes, all subscriber custom fields still show up in the field map.

To make it even worse, since subscriber (local) field show up, if the subscriber creates a field with the same name, then the Display Types are messed up because the field only shows up ONCE in the map...

Additionally this actually returns the value of the field yet the field describe says this field does not exist


How can a developer dynamically get fields identified by the subscriber from the package to get describe information if the namespace has to be removed....

(Use case, custom merge documents where the subscriber uses field API Names including namespace to display information. Display types is used for formatting)

Is this a bug???

@sfdcfox -

If I have a field of type DATE - NS__Field__c Customer creates a field of type BOLEAN Field__c

When I in the namespaced managed package get the field map the DisplayType of the field obtained using Field__c comes back as BOOLEAN instead of my namespaced type of Date.

@Daniel & @sfdcfox

It seems that it is documented so it is not a bug. However, when a package is installed in a subscriber org a field in their org with the same name will cause issues with the getMap() method since there is no namespace for their org.

Daniel was kind enough to point out the last paragraphs of the following document:


Thanks for the discussion, not really solved as the problem is still there, but it is a documented problem.....


  • Sounds like a bug (or at least a problem with the way it has been implemented). As you say, you can't distinguish between a managed package field and custom field without the namespace. Commented Mar 25, 2015 at 2:02
  • @DanielBallinger - Ugh - Now to spend a bunch of time trying to figure out how to set it up so a support person can replicate. Means I am going to have to teach them how to debug......Curious if anyone else is seeing this. I created a patch to debug all the possibilities so I know its happening. Updating package now to remove the namespace so it at least works but with a caveat...
    – Eric
    Commented Mar 25, 2015 at 2:11
  • 1
    Update on the case - Closed out of Scope - Pointed me to forums....SF makes it impossible to point out bugs / inconsistency / etc without paying for premier support....This is a real issue that customer fields are showing up in describe calls within the managed package when our fields are not namespaced in the same call.....
    – Eric
    Commented Mar 26, 2015 at 0:03
  • It's sad, but it seems to be the current state of play. You can't raise platform bugs without posting to the developer forum and hoping it gets picked up. It requires way too much effort on our part to try and help get bugs fixed. My favourite is when support asks you to post security problems that could be used for DOS attacks or to bypass session handling publicly on the forums. Commented Mar 26, 2015 at 0:36

1 Answer 1


This isn't a bug. It's working as documented. Fields and objects do not return their namespace when code from the same namespace calls it. It's a type of scoping mechanism. And yes, subscribers that build a field that duplicates one of your fields will find that your code cannot access it, query it, or in any way interact with it, short of calling the REST or SOAP API without the namespace. And, for the record, you should not be using the namespace for merge fields within your package, but the subscriber would need to use the namespace in their own org's configuration (e.g. validation rules).

The mechanism is meant to protect your code from changes that subscribers might do to break your code (e.g. create a field without a namespace that your code references of the wrong data type, suddenly causing your code to get confused and crash). However, that protection comes at a cost, and that cost is a bit of inaccessibility (shadowing objects and fields), and a bit of confusion. All you need to remember is that your namespace should not be referenced in your code anywhere. Your code is walled off from the subscriber's configuration (more or less), so any request for anything that comes from your own package will always belong to your package.

There are a few obscure namespace bugs, though, that I don't think they've ever sorted out. Notably, "bare" merge fields need to have namespace references in Visualforce pages, but those that are inside tags, like apex:outputText, will be magically patched when it arrives in the subscriber org. Try looking at the source for a Visualforce page in a subscriber org and you'll see what I'm talking about. Your namespace will magically appear in the merge field, even when it was not in the original source.

  • You say "And yes, subscribers that build a field that duplicates one of your fields will find that your code cannot access it, query it, or in any way interact with it," but the problem is I CAN interact with it. If they create a field of type boolean with the same name as my field of type date, when my code does the field describe it returns a field type of BOOLEAN and NOT date. So their field overwrites mine in the map. The only way to prevent this would be to use namespace.... I have updated my question to reflect this
    – Eric
    Commented Mar 25, 2015 at 4:15
  • 1
    Also, as for the namespacing of the merge fields, thats how SF puts them out in their org when we display a picklist of available fields......If I remove the namespace there, then when I try to get the value of the field from the object dynamically is says it does not exist because the namespace is not appended....Either way one would think if the namespace is required to get the value of the field dynamically it would make sense that it would appear in the fieldMap from a describe call. Thank you for your comments, just trying to have a dialog as this is a catch 22
    – Eric
    Commented Mar 25, 2015 at 4:19
  • Maybe add a doc quote from Accessing All Field Describe Results for an sObject. See the last couple of paragraphs. I still think the conflict between the managed package fields and the no namespace local fields is a bit off. Commented Mar 25, 2015 at 8:16
  • 1
    @DanielBallinger - The last paragraph makes sense except for orgs that do not have a namespace and have the package installed.......I think this is where the problem is.
    – Eric
    Commented Mar 25, 2015 at 12:20
  • Your field should shadow their fields. That does indeed sound like a bug. I remember it working correctly about a year and a few months ago when I left a project where we were playing around with all sorts of namespace problems, but that wasn't one of them. Sounds like maybe a regression issue. Hopefully support will even look at the problem, though, because it sounds like the kind of thing they'd want to close the case as out of scope for, but hopefully you'll have some luck with them. I'd rather see a PM look into this...
    – sfdcfox
    Commented Mar 25, 2015 at 13:49

You must log in to answer this question.

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