An organization I'm developing a managed package for has a custom field on their User page. Adding that field to my organization User page allows me to test my code, but as soon as I try to install the package in my client's organization, we get an error that the custom field already exists there. If I take the custom field out of our organization's User page, then I can't compile any classes that refer to it. How do I get around this?

  • 2
    If it is managed package then you will never get that error cause your package has a namespace. Sounds like it is an unmanaged package.
    – Eric
    Oct 16 '15 at 18:37
  • You are correct. I thought i had made it managed, but I must have forgotten to. Thanks. Hmmm, now how do I mark your answer as correct?
    – Alan Lau
    Oct 16 '15 at 19:14
  • 1
    I just added it as an answer. Also, pay attention to what sfdxfox said
    – Eric
    Oct 16 '15 at 19:24
  • @AlanLau If you add it to a managed package, it will affect all subscribers. If this is a one-off feature, you might not want to add it to your package. Of course, if the managed package is only for one subscriber, there's no issue. You'll just have to migrate some data.
    – sfdcfox
    Oct 16 '15 at 19:43

A managed package will have a namespace and thus should never conflict with subscriber orgs.

With that said I believe you are using an unmanaged package as that is the only way that error would appear....

When you do make it managed, keep in mind the subscriber org will have to migrate all use of their original field to your managed package field.


You'll have to use Dynamic Apex and/or Dynamic Visualforce in order for you to avoid breaking your compilation and to avoid getting conflicts.

In Apex Code, that looks something like this:

SObjectField someField = Schema.getGlobalDescribe().get(objectName).getDescribe().fields.getMap().get(fieldName);
// You can now reference get/put methods
// Use appropriate data type or you'll get a runtime exception
String fieldValue = (String)record.get(someField); 
record.put(someField, 'Hello World');

You can also use plain strings with get/put. These methods are case-insensitive, but you must remember to use __c for custom fields and objects, as usual.

In Visualforce, you'll need to use a similar technique:

<apex:inputField value="{!record['fieldName']}" />

To query the field, you'll have to use Database.query to generate dynamic queries (a string).

As long as you don't explicitly reference the field/object, then it won't be a required part of the package.

  • This still causes an issue as a field in the package with the same name as a field in the org, you never know which field you are going to get....I believe this bug has not been fixed yet. i.e. if you have Account__c and ns__Account__c, there will be an Account__c key but it may or may not be the managed package field...salesforce.stackexchange.com/questions/70207/…
    – Eric
    Oct 16 '15 at 19:35
  • @Eric I was rather understanding that they wanted to reference a subscriber's field. Of course, once a managed package uses the same field, the subscriber's field is inaccessible to the managed code. This technique is correct if you don't want to add the field to your own package. Of course, you realized that the package wasn't managed. Nice catch.
    – sfdcfox
    Oct 16 '15 at 19:42
  • Thats the problem, the subscribers fields DO show up using a describe call when done from a manged package.......
    – Eric
    Oct 16 '15 at 19:52
  • @Eric Oh. That's a terribly old bug. I thought they would have fixed that by now.
    – sfdcfox
    Oct 16 '15 at 19:52
  • As of a few months ago it was still happening. I will have to check with the winter 16 soon to see if it is fixed...
    – Eric
    Oct 16 '15 at 19:54

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.