Skip to main content
How to Deploy CPQ with Gearset Pipelines

How to incorporate Salesforce CPQ, Advanced Approvals and Billing into Pipelines workflows and deploy metadata and config data together.

Richard Owen avatar
Written by Richard Owen
Updated over 2 months ago

License requirements:
Both Automation and CPQ licenses are required for Gearset teams to have access to this feature.

Gearset Pipelines supports Salesforce CPQ, Advanced Approvals and Billing configuration data for deployment alongside regular metadata in your Pipelines process, using the same git repository.

CPQ configuration can be deployed through the Pipeline in the same PRs as standard metadata, and the Gearset External ID fields will be deployed and kept in sync across environments through the deployment process.

To include CPQ in your Pipelines process, the following setup steps are recommended:

Before you start: Ensure that Gearset External IDs for all CPQ configuration data are aligned across all orgs in which CPQ is actively used. If this is not the case, please see and follow this guide to align them correctly:
โ€‹Setting up your orgs for successful CPQ deployments via a full copy sandbox refresh approach

  1. Populate CPQ metadata into the master branch of your repo. All CPQ configuration data you intend to be configurable through your Pipelines process should be included here. To populate CPQ into the repo, use the following guide:

    Note: To ensure good performance from your repo, we recommend that the size of CPQ configuration in your repository should not exceed 1GB. Typically, this would correspond to an upper limit of approx. 1 million pricebook entries, or around 20,000-30,000 products.

  2. Ensure that this CPQ configuration data is aligned across all branches which underpin orgs in which CPQ is actively used.

    1. If using a new repo with a new pipeline, push CPQ config data to the master branch alongside metadata, then create your other Pipelines branches from this to ensure alignment.

    2. If you have an existing repo, create PRs to push the CPQ config data from the master branch to the other branches in use - as the External IDs are already aligned, this should simply ensure that the config data in the branch matches that already in the orgs.

  3. Create new CI jobs for each environment in which CPQ is actively used alongside core metadata to include the CPQ metadata types required. Ensure you also have the CPQ managed package selected (in the filter of your CI jobs), along with any metadata required for CPQ deployments.

    Note: If you wish to use existing CI jobs, the first run for the job after adding CPQ components to the metadata filter will attempt to deploy all CPQ items in the repo to the target. As such, new CI jobs are strongly recommended.

  4. Add these new CI jobs into your pipeline, replacing the original CI jobs in the Pipeline. Any PRs open against the branches here will be preserved. If setting up your pipeline for the first time, see the following document and incorporate CPQ into your CI jobs here when setting them up: Setting up your first Gearset pipeline.

  5. Start using CPQ in Pipelines! You can create PRs with CPQ configuration data and Salesforce metadata - on merging to the first branch and deploying to the org, the PR is raised against the next Pipeline environment in the same way as with any other PR.

We recommend that teams use Delta CI with Pipelines for CPQ in the same way as is recommended for metadata-only jobs - this way, only the new changes will be deployed when you push changes.

There are some differences in behaviour which should be noted between the core pipelines process and deployments which include CPQ:

  1. PR Validations - Validations will be run on metadata in a PR, but not on the CPQ config data. If the metadata config passes validation, the PR may be merged and deployment started, but if there are issues with the CPQ deployment, this may cause the deployment to be only partially successful.

  2. Partial success due to CPQ deployment failure. If a CPQ deployment fails to deploy some config data, this status is shown in the Pipelines UI for the deployment. Any errors here can then be found and remedied as needed.

Did this answer your question?