Long ago, I added a field Type__c to Contact on our production org. Now, I'm using SFDX to develop an unlocked package with code that refers to that custom field, like someContact.Type__c = 'Student'.

With a newly-created scratch org, using force:source:push on this package gives the error

Variable does not exist: Type__c

because the custom field hasn't been defined in the scratch org. That makes sense, and I can fix it by retrieving the metadata for Contact from production and using force:mdapi:deploy to deploy that metadata into the scratch org. Then force:source:push works and my tests run successfully.

The problem comes when I try to create a package version. When I use force:package:version:create I get the Variable does not exist: Type__c error again. The field is defined in both production and the scratch org, so I don't understand "where" the package version is being created such that it doesn't see that field.

Accessing a custom field from an SFDX-based package seems like a pretty common use case, so I have a feeling I'm misunderstanding something basic. Can anyone help me figure out what I'm doing wrong, and offer an approach that works? Thanks very much in advance for your help.

1 Answer 1


The field needs to exist in the package (or a parent package). This means you'd have a file in objects/Contact/fields/Type__c.field-meta.xml that represents the field in question. A package must be a complete replica of the data, including any dependencies.

  • Thanks! That's the approach I took in an earlier attempt. I had converted the Contact metadata to source format, and included that as part of the package under force-app/main/default/objects/. That worked, but with a nasty side-effect: SF now says it will delete the custom fields if I uninstall the package. Worse, I'm unable to install a second package that refers to the custom field using the same technique, as I get an error that Type__c is already defined in another package. How can I work around that? Feb 27, 2019 at 20:29
  • @JeffGarbers You use dependencies to manage this. The base package would have the common fields/objects/etc, and dependent packages would add additional metadata. In your example, Type__c would be in a common package A, and two dependent packages B and C with their respective code.
    – sfdcfox
    Feb 27, 2019 at 20:43
  • Okay, that's a strategy I was thinking about. I still have a Catch-22, though, I think. If I move all the custom fields and objects into package A, I can't install A because there's already an existing package B that "defined" some of those objects. And if I uninstall "B", SF says it'll delete the fields and associated data...!? Thank you again for your help! Feb 27, 2019 at 20:47
  • Oh, and: I tried uninstalling my "B" package from a sandbox, just to see if it would actually delete the custom fields it carried. Instead I got an error saying that other parts of SF were using those fields, so I couldn't delete the package. I have a bad feeling I've gotten myself well stuck. Feb 27, 2019 at 20:49
  • 1
    @JeffGarbers Nice. You might want to post your own answer with more details. I'd be interested in seeing the exact steps, and I suspect it will help other people.
    – sfdcfox
    Mar 4, 2019 at 12:35

You must log in to answer this question.

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