Include Cloned CPQ App in Scratch Org Built from Org Shape

cpqsalesforcedx

I recently started using the Salesforce DX CLI to spin up scratch orgs. I managed to generate a scratch org that mirrors my production Salesforce environment using the shape org feature.

In our production environment there is a CPQ application that was cloned from the CPQ package. We have modified the cloned CPQ app structure with custom objects, fields, flows, etc. I would like to include this structure within my scratch org that I created from production, but I do not know how. Can someone point me in the right direction? My end goal is to create a scratch environment from production that includes this CPQ application.

NOTE: This question has been asked here before in some form, but many of the answers on the salesforce stackexchange site are several years old and pre-date the final release of the shape feature.

Thank you ahead of time for any help you can give me.

Best Answer

I found an alternative approach to this issue using Salesforce's DevOps Center Beta. This allowed me to setup pipelines connected to Github repos and branches and easily deploy changes (including those made to CPQ-specific components) through various environments to production. To utilize this feature I recommend this tutorial: Salesforce DevOps Center.

Related Solutions

[SalesForce] Removing old hub org, or non-scratch org from Salesforce DX org list

It would be nice for this to be something in the actual CLI commands: the ability to clean up old orgs that are no longer needed.

For the time being, you need to manually cleanup the DX configs in the local installation.

On mac/linux, you can find your DX config folder, called .sfdx in your user home directory.

cd ~/.sfdx

On windows, you can use %USERPROFILE%\.sfdx

In that folder there are a host of .json files, named for the username of the admin user you registered for that org. In my case, in this instance it was called peter@dx.pilot, so sure enough, there it was:

peter@dx.pilot.json

Inside the file, or the hashes for current access token, refresh token, and all the other OAuth goodness that allows DX to access your org. So I simply deleted that file:

> rm peter@dx.pilot.json

That appears to have cleaned it all up, and I'm no longer bothered by the "invalid grant" message and the shadow org.

[SalesForce] How to use Salesforce DX with an existing sandboxes

There are different types of hurdles you will need to overcome to deploy to a scratch org. The same issues apply if you're trying to deploy to a developer org (not developer sandbox), but scratch orgs allow you to overcome some of them.

From easiest to hardest:

Org Edition and Features
Org Settings
Org-Specific Metadata
Org-Specific Limits
Known Issues

Org Edition/Features

Some metadata can only be deployed to orgs with specific features enabled. For example, the CurrencyIsoCode fields can only be deployed if the MultiCurrency feature is enabled during scratch org creation.

You need to identify which features to enable in your scratch org definition file.

Org Settings

Some metadata can only be deployed to orgs when other metadata has specific values. For example, Case.SourceId can only be deployed if the IsLiveAgentEnabled setting is enabled.

These settings are stored as metadata so you can store them under version control. You can also deploy them to an org so you can adjust them while troubleshooting deployment errors. (Although some settings can't be changed through the metadata API, or can't be disabled once enabled.)

sfdx force:org:create supports setting some of the org settings so you can update your scratch org definition file once you figure out which settings you need enabled.

Org-Specific Metadata

Some metadata can be tied to data in an org. You'll want to try to break these dependencies by updating your metadata.

For example, Workflow alerts can reference Users. Since these Users won't exist in the scratch org, you will probably want to update these to use Groups or Roles, which are stored as metadata, instead.

Custom Org Limits

You might have non-standard limits available in your production org such as an increased number of Sharing Rules allowed. This will have to be addressed through the new Org Shape functionality.

Known Issues and Bugs

There's at least one known issue related to history tracking that will might prevent deploying the metadata from a large production org to a scratch org for the time being.

If you run into other errors, check the known issues and report them.