When I attempt to push a custom profile to my scratch org that contains a layoutAssignment to the AccountContactRelation object, I get the following error:

In field: field - no CustomObject named AccountContactRelation found

From what I can tell of the documentation about the object, this may be in relation to PersonAccounts feature (which I see listed in the Scratch Org Definition documentation. But from what I see here, it would seem there should be some "Shared Contacts" or "Financial Cloud" feature:

AccountContactRelation is a standard object that is available through the Shared Contacts feature. Custom fields extend the AccountContactRelation standard object for use in Financial Services Cloud.

Am I correct to assume the fix here is adjustment to the scratch org definition file? And if so what is the appropriate modification?

Note: It would seem beneficial for Salesforce to produce some documentation about the features and preferences listed, for many, their only mention on the internet as a whole is from this single bulleted listed they've provided

Update: Workaround

If I go to Account Settings in the scratch org and manually turn on "Contacts to Multiple Accounts Settings" this seems to resolve the issue but this is a horrible solution.

enter image description here

  • 1
    Very much doubt Person Accounts is what you are after - that's a very different feature. You are right - it is typically referred to as Shared Contacts or something similar - but let me see if the Twitter world can shed some light Commented Feb 2, 2018 at 0:51
  • It might be possible to pull down the Account Settings entity with the Metadata API, archive it, and script a deploy of that object to your newly created scratch orgs to automate this. I'm not sure if that setting is in the MDAPI or not.
    – David Reed
    Commented Mar 14, 2018 at 22:15

6 Answers 6


Current they best solution for this at this time is using the OrgSource Pilot program. Obviously it still has some work but it's definitely a lot easier to work with then not having it. First step is to request and gain access to it. Once you run a quick test with the pilot org they provide you then you can request to have your production org enabled with the feature.

The steps are pretty easy. Essentially you need to create a shape (this is essentially what a definition file is, but this is being generated by your given org).

sfdx force:org:shape:create -u Production

Then once that completes you can see it in your list like so:

sfdx force:org:shape:list

enter image description here

Once this is complete you can create a scrath org definition json using the source org id of your shape:

    "orgName": "My Company",
    "sourceOrg": "00D1N000001Bn#####",
    "hasSampleData": false

Then create a new scratch org using this definition file:

sfdx force:org:create -f ./config/production-scratch-def.json -d 30 -s -a test

That's it. Doesn't solve every problem yet but it does solve some. I noticed right away that this still doesn't account for things like Forecasting... (at least it didn't at the time).


it's old question, but in summer19 released a new feature called --"features":["ContactsToMultipleAccounts"], we r using same feature for "Contacts to Multiple Accounts Settings"


The ContactsToMultipleAccounts feature attribute has been deprecated since Winter '21 per the release notes.

If your scratch org definition file specifies this feature, delete it from the file. You’ll receive a warning in Winter ’21; the feature will be deprecated in Spring ’21.

Remove the feature, then add the enableRelateContactsToMultipleAccounts setting to your scratch org definition file.

To enable this configuration, add the attribute for it under accountSettings in your scratch org definition file.

"accountSettings": {
    "enableRelateContactToMultipleAccounts": true


So, this seems one of some features that you can enable from inside the org, but not in the scratch org def. file. If I remember correctly, there were some features like this one that don't have (yet?) a parameter to be passed in the configuration file.

Check out the documentation for Scratch Org Definition Configuration Values.

It states that your functionality is available as PersonAccounts, from what I can see:

You can specify multiple feature values in a comma-delimited list in the scratch org definition file (for example):

"features": ["MultiCurrency", "AuthorApex"],


@Xtremefaith answer using org shape is good one, so far I have been using org shape to create my scratch orgs.

But when it comes to enabling Contacts to Multiple Accounts feature, I realized few things. This feature won't get enabled in Scratch Org though the Org Shape created from the respective Prod Org has it enabled. Strangely manually if I try to turn on the checkbox in Scratch Org I get an error

"You can't enable Contacts to Multiple Accounts with the feature in its current state. Contact salesforce.com for help enabling Contacts to Multiple Accounts."

So I have reverted to using "features": ["ContactsToMultipleAccounts"] in my project-scratch-def.json file and discontinued using org shape.

I suspect the Salesforce org shape functionality is not perfected yet , it being still in beta at the time of writing.


I know this post is old but figured id share my findings as it may help a lost soul who stumbles on this.

This problem is not feature specific (although it affects some features more often than others).

I've been working with a very heavy scratch org def file for the last 2-3 years on one of my projects (its about 500 lines).

I have a daily job that creates a pool of scratch orgs to be used for my ci/cd process. I found this necessary due to the extrodinary amount of time it takes to fully spin up a scratch and deploy G1 packages (roll on scratch snaphots!).

What i have observed is that features randomly fail to activate on scratch creation, this is truly random and i cannot recreate this on demand. This feature in particular is notorious for not activating properly, so much so that we have written a script to query the created scratch post creation for the presence of objects/fields that should be available if the feature(s) have been activated correctly.

Should this fail we queue the scratch for deletion and retry building another until we have suitable scratch (essentially a scratch creation loop) the worst i have witnessed to date is it taking an hour to actually build a scratch that was configured properly (god knows how many scratch orgs it tried to create in that time) - I'm talking a plain scratch here thats configured properly - no packages no meta deploy.

I was hoping org shape would resolve this now its GA, alas the first scratch created from the org shape failed to enable person accounts properly and the subsequent meta deployment failed.

Until this gets "stable" im going to stick with the scratch def and custom script which checks for proper feature activation.

You must log in to answer this question.

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