My app has some custom fields on an object which is a part of a packaged app (so this is a namespaced-object, in the namespace bt_stripe).

When trying to push the code with SFDX into scratch org, I've getting the following error:

$ sfdx force:source:push -u cpq-scr-1


Must specify a non-empty label for the CustomObject

The object definition XML-s doesn't have label definition, as they are defined already in the package.

For example, force-app/main/default/objects/bt_stripe__Transaction__c.object-meta.xml:

<?xml version="1.0" encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata"/>

Apparently, SFDX doesn't recognise that these objects definitions are special and wants to deploy them as they would be 'normal'. Any ideas how to deploy such an object definition?

  • 1
    What do you get back if you manually add the field to the managed custom object in the scratch org and then do a force:pull? Does it produce a slightly different bt_stripe__Transaction__c.object-meta.xml – Daniel Ballinger Oct 4 '17 at 19:12
  • @DanielBallinger the objects are already there (as the bt_stripe package is installed in the scratch org), but there is nothing to pull, as the non-packaged package can't be created (pushed) :( – Peter Tempfli Oct 6 '17 at 5:54
  • I'm having this issue :( – Tyler Zika Feb 28 '18 at 0:24

This is a known bug and a fix is currently being worked on. The bug is in the source:convert process.

| improve this answer | |
  • as a workaround, you can just delete the <NAMESPACED-OBJECT>.object-meta.xml files; also remove these references from .sfdx/orgs/ORGNAME/sourcePathInfos.json – Peter Tempfli Jan 24 '18 at 6:20
  • @Dave Carroll do you have a link to the SF known issue of this? – Seyitbek Oct 28 '19 at 21:26
  • 1
    @Seyitbek To clarify, it is not a known issue, rather a bug. Known issues are have a slightly different connotation. I will attempt to find the bug since this is now 1.7 years old. – Dave Carroll Oct 29 '19 at 23:03
  • @Seyitbek According to our bug tracking system, this fixed in the v41.18.3 release. Is your CLI up to date? – Dave Carroll Oct 29 '19 at 23:10

I encountered the same issue and 'resolved' this by removing the "object-meta.xml" file. Seems like a DX bug to me.

| improve this answer | |
  • yeeeees, but the problem is that this packaged object has additional fields in my non-packaged app -- so I need that file :( – Peter Tempfli Nov 30 '17 at 6:33
  • When you converted the code to DX format, any non-packaged fields, should be represented as individual files in the fields directory. You should then be able to push these into the scratch org, and also pull any changes you make in the scratch org. I would recommend you start over by creating a new scratch org, install the package, then push in your code (which should have those "object-meta.xml" files removed). – Tommy Hogan Nov 30 '17 at 16:57
  • This one works, and we are in 2020! – Mert Akcakaya Apr 20 at 16:17

We have the same issue after using "sfdx force:source:convert -r source-code/ -d mdapioutput/" - in the mdapioutput folder, all the objects become pretty much empty except the header and trailer. We have a work around - after covert, copy the original objects to mdapioutput to override those pretty much empty newly converted files, then deploy. It works.

| improve this answer | |

As it turned out, for packaged objects you need to delete the <NAMESPACED-OBJECT>.object-meta.xml from the object directory -- than it deploys nicely.

| improve this answer | |

I had the same symtomps but I had to correct a uppercase letter in the name of my object folder and in the name of my metadata for the object.

(Be careful because my VSC, gitlab wasn't updating my correction.)

| improve this answer | |

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.