CLI Scratch Org misbehaving behaviour on enableRelateContactToMultipleAccounts

Question

I am using CLI to create Scratch Orgs based from a definition file. The objective is to enable ContactsToMultipleAccounts when pushing our source data.

The issue, is the Scratch Org is being created with Allow users to relate a contact to multiple accounts being checked in the Account Settings. However, the Account Contact Relationship object isn't being created. I'm also unable to see the what-should-have-been-created correct Related Lists on the Account and Contact page layouts.

Because of this, when pushing my metadata into the org after creation, I'm getting deployment failures as there are data dependencies on that object.

A manual fix, is to manually uncheck this option in config, and recheck before pushing. But I still believe this to be unintended behaviour.

I have enabled ContactsToMultipleAccounts in both the 'features' section, but also as an 'accountSettings' option in the project-scratch-def.json file.

How can I ensure that the setting acts as expected on creation of a scratch org? Rather than requiring the manual step

Really appreciated

Step 1. Command to create Scratch Org sfdx force:org:create -s -f config/project-scratch-def.json --setdefaultusername -d 7 -a contactToMultipleAccountEnabled

At this point, I am expecting the Account Contact Relationship object to be created successfully

Step 2. Command to push my source sfdx force:source:push -f

*Now the deployment will fail unless I manually uncheck & recheck the Allow users to relate a contact to multiple accounts option in Account Settings as part of Step 1.

project-scratch-def.json

{
"orgName": "Scratch Org",
"edition": "Enterprise",
"features": ["EnableSetPasswordInApi", "SharedActivities", "DefaultWorkflowUser", "ContactsToMultipleAccounts", "LiveAgent", "ServiceCloud", "WorkplaceCommandCenterUser", "CaseClassification", "Entitlements", "CaseClassification"],
"settings": {
  "lightningExperienceSettings": {
    "enableS1DesktopEnabled": true
  },
  "accountSettings" : {
    "enableRelateContactToMultipleAccounts" : true
  },
  "mobileSettings": {
    "enableS1EncryptedStoragePref2": false
  },
  "caseSettings": {
    "emailToCase": {
      "enableEmailToCase": true
    }
  },
  "quoteSettings": {
    "enableQuote" : true
  },
  "entitlementSettings": {
    "enableEntitlements": true
  },
  "emailAdministrationSettings": {
    "enableEnhancedEmailEnabled": true
  }
},
"objectSettings" : {
  "opportunity": {
    "sharingModel" : "private"
  },
  "case": {
    "sharingModel" : "private"
  }
}

}

Answer 1

We ran into the same problem with our scratch orgs, and by creating a new plugin for the wonderful sfdx-browserforce-plugin, we were able to work around this. For more details on that, look at the following PR: https://github.com/amtrack/sfdx-browserforce-plugin/pull/470

Actually getting it to work required several steps, which I will go into here.

Step 1: Scratch org creation

When creating a scratch org, you should have the following in your definition json file:

  "features": [
    ....
    "ContactsToMultipleAccounts"
  ],
  "settings": {
    "accountSettings": {
      "enableRelateContactToMultipleAccounts": true,
    }
  }

Of course, you might have more settings and features enabled, but this is adding support for AccountContactRelations to the scratch org. Once it's created, you will see that the feature is enabled.

Step 2: Check if AccountContactRelation is available

We are scripting the entire process with bash in Azure pipelines, and we use the following command to get a '0' or '1' indicating if the AccountContactRelation object is available:

HAS_ACR=$(sfdx force:schema:sobject:list | grep AccountContactRelation | wc -l | sed s/[^0-9]//g)

If this gives '1', then no other work is required. If '0', then even though the feature was enabled, the AccountContactRelation object is not available and you need to go to the next step.

Step 3: Install browserforce plugin

echo y | sfdx plugins:install sfdx-browserforce-plugin

Step 4: Create both 'enable' and 'disable' configs

Create a file 'config/browserforce-acr-disable.json':

{
  "$schema": "https://raw.githubusercontent.com/amtrack/sfdx-browserforce-plugin/master/src/plugins/schema.json",
  "settings": {
    "relateContactToMultipleAccounts": { "enabled": false }
  }
}

And a file 'config/browserforce-acr-enable.json':

{
  "$schema": "https://raw.githubusercontent.com/amtrack/sfdx-browserforce-plugin/master/src/plugins/schema.json",
  "settings": {
    "relateContactToMultipleAccounts": { "enabled": true }
  }
}

Step 5: Disable and then re-enable using browserforce

  sfdx browserforce:apply -f config/browserforce-acr-disable.json
  sfdx browserforce:apply -f config/browserforce-acr-enable.json

(we added a sleep of 10 seconds between these, because it triggers an asynchronous process in the org and enabling immediately after disabling did sometimes result in issues).

The entire script

HAS_ACR=$(sfdx force:schema:sobject:list | grep AccountContactRelation | wc -l | sed s/[^0-9]//g)
echo "ACR active status: $HAS_ACR"

if [ "$HAS_ACR" == "1" ]
then
  echo "ACR is available, skipping..."
else
  echo "Disabling ACRs first ..."
  sfdx browserforce:apply -f config/browserforce-acr-disable.json
  
  echo "Sleeping 10 seconds, giving some grace time to the scratch org to process the disabling"
  sleep 10
  
  HAS_ACR=$(sfdx force:schema:sobject:list | grep AccountContactRelation | wc -l | sed s/[^0-9]//g)
  echo "ACR active status: $HAS_ACR"

  echo "Enabling ACRs ..."
  sfdx browserforce:apply -f config/browserforce-acr-enable.json
  
  echo "Sleeping 10 seconds, giving some grace time to the scratch org to process the enabling"
  sleep 10
  
  HAS_ACR=$(sfdx force:schema:sobject:list | grep AccountContactRelation | wc -l | sed s/[^0-9]//g)
  echo "ACR active status: $HAS_ACR"
fi

Answer 2

After a few days of on-and-off testing, and reporting to Salesforce as a valid bug. The issue is somewhat intermittent, 3/10 times the org behaves as expected. 7/10 times it fails.

https://trailblazer.salesforce.com/issues_view?id=a1p3A000001PYYlQAO

My solution going forwards (until this is fixed).

Fix for People:

• Use Individual Scratch Orgs
• Before pushing metadata into Org, manually re-enable the Account Setting

Fix for Pipeline:

• Take advantage of using dedicated Sandboxes rather than Scratch orgs for now.