3

I am pushing Metadata from a (namespaced) scratch org with that definition

{
  "orgName": "my_DEV",
  "country": "US",
  "edition": "Developer",
  "language": "en_US",
  "hasSampleData": true,
  "features": [],
  "settings": {
    "orgPreferenceSettings": {
      "s1DesktopEnabled": true,
      "chatterEnabled": true
    }
  }
}

into a packaging org using this SFDX command

sfdx force:source:deploy -p ./sfdx-source/appw  -l RunLocalTests -w 15 -u mydev

It fails as Account is missing many fields that it has in the scratch org.

sfdx-source/appw/main/default/objects/Account/fields/CleanStatus.field-meta.xml Could not resolve standard field's name. (266:13) sfdx-source/appw/main/default/objects/Account/fields/OperatingHoursId.field-meta.xml fullName must end with: __c or __kav or __x or __b or __xo or __e or __p or __mdt (312:13) sfdx-source/appw/main/default/flexipages/AccountRecordPage.flexipage-meta.xml Your org doesn't have access to component runtime_sales_social:socialPanel.

Looks like I am missing:

  1. Account.CleanStatus
  2. Account.OperatingHoursId
  3. runtime_sales_social:socialPanel Component

When I google this it looks like Data.com Clean fields which I never activly activated. How can I get rid of those fields.

1 Answer 1

4

"Regular" (Developer Edition) scratch orgs don't have the same feature set as Enterprise Edition orgs, or any arbitrary org. Packaging orgs often have a lot of features turned off, as well, to avoid inadvertent dependencies.

That makes pulling Profile metadata out of a scratch org for deployment to a non-scratch org... difficult, in many cases, and Data.com is a common culprit in my experience.

Here, though, it looks like you just have the actual field metadata for a number of standard fields, which are part of the Data.com feature that's enabled by default in Developer Edition scratch orgs. You probably don't want that metadata in your source tree at all, since it's not part of your package, and I'm surprised it got pulled in the first place. I'd simply delete all of the standard field metadata.

I don't know what feature the runtime_sales_social:socialPanel component is part of off the top of my head. If that's something you intended to include in your package you'll have to identify the feature and activate it in the packaging org to allow deployment.

5
  • Maybe it would be wise to add them in .gitignore and .forceignore as an exculsion.
    – Raul
    Jul 24, 2019 at 13:28
  • You were right. The Packaging Org was a "Partner Developer" org but the scratch org was just "Developer". Jul 24, 2019 at 13:29
  • @Raul I would agree except I'm not sure why they ended up in the source tree in the first place. Typically I wouldn't expect to see those standard fields come down at all.
    – David Reed
    Jul 24, 2019 at 13:32
  • @DavidReed That's how DX pulls fields, actually (e.g. force:source:retrieve). I had a similar issue with fields being pulled down and causing 2GP errors, too.
    – sfdcfox
    Jul 24, 2019 at 15:46
  • Ah, thanks, @sfdcfox. I virtually never use source:retrieve so I haven't seen this one before.
    – David Reed
    Jul 24, 2019 at 15:48

You must log in to answer this question.

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