💡 To use Gearset Pipelines you will need an Automation licence.
What is the advantage of using an automated Gearset Pipeline?
Gearset Pipelines form part of the end to end DevOps lifecycle, introducing automation to your deployment landscape and allowing a team to fully leverage the advantages of version control and automated deployments.
Many teams struggle to manage their ARM implementations as they scale not because of the complexity of the configuration (although this is also a consideration) but because of the classic challenges that confront all Salesforce teams -
overwritten changes
unclear change management processes
increasing overhead from a ballooning list of manual steps
These are problems that DevOps solves, not just through the application of a version control and automated deployments but through an understanding of those as part of the wider DevOps lifecycle.
💡 Security, testing, collaboration and automation are all critical DevOps practices and should be applied throughout the lifecycle — not just at one stage. That’s why these four things are featured in the “halo” around Gearset’s DevOps lifecycle diagram.
How can I start using Gearset Pipelines for my Agentforce Revenue Management configuration?
We recommend the following steps are completed before setting up your pipeline to automatically deploy Salesforce CPQ or Agentforce Revenue Management configuration.
Before you start
We recommend familiarising yourself and your team with the process of comparing and deploying your Salesforce CPQ or Agentforce Revenue Management configuration data from org to org before introducing it to your Pipeline. This will allow you and your team to become familiar with the way the dependency analysis and deployment sequencing works before those processes are automated as part of the pipeline.
Make sure you have completed the External ID setup process using the Gearset External ID setup wizard. This introduces a unique External ID to all of your ARM records, allowing Gearset to track them as they move between environments and treat them in the same way as metadata. You will need to run the wizard on all of the orgs you intend to use as part of your pipeline, as Gearset will not deploy the configuration data if either the source or target do not have a Gearset External ID field, to prevent duplicates being created.
Assess whether you need to align the IDs between your orgs. Gearset derives the Gearset External ID from the Salesforce Record ID, the same record created in two different orgs (by hand or by a non-Gearset deployment) will have a different Salesforce Record ID, and therefore different Gearset IDs. You can use Gearset to align your IDs, or use the sandbox refresh approach to make sure that you are starting from a place of alignment.
You may also want to review this guide: Comparing and deploying Revenue Cloud configuration with source control.
Setting up a pipeline for Agentforce Revenue Management deployments
Before you begin, if you would like to become more familiar with Gearset Pipelines and how you can leverage them please get in touch over the in app chat to arrange a demo.
If you are creating a new Gearset Pipeline:
Use the pipeline setup wizard to create your pipeline and new repository. When you reach the point of populating your repository make sure that you include ARM configuration data as well as your metadata.
At the point you are prompted to select what you want to populate the repository, select "manage custom filters" to explore your filter options.
Include the configuration data (like the PCM module) and metadata (like Expressions Set Definition) that you plan to move through your pipeline, and save the filter.
Name the filter. This is pipeline filter, ensuring the same components are consistently deployed between your environments, as well as determining the base set of configuration in your pipeline.
After the pipeline is created it's time to create your first static environment, which will be your Production org.
A static environment is one of the environments on your pipeline, where you can see the changes which are waiting to be deployed to your orgs, and set up automated processes to assess the deployability, quality and review status of your changes as they move through the Pipeline.
After choosing your source and target you can move through the rest of the setup steps (you can find out more about the options available to you and decide if you want to use something other than the default). You will notice that the filter created earlier has been automatically selected.
After you have saved your static environment you will see it in the pipeline. Gearset will make a baseline run to understand the current difference between your main branch and Production, so that we can make Delta deployments in the future.
Add a new static environment for each of your testing and integration sandboxes.
Duplicate your first environment.
Make sure to give each of your new static environments their own source branch, matching the name of the target.
Connect the environments, so you have a clear map of the journey your changes will go on from development to release.
Add your developer sandboxes - these are the sandboxes which are going to contribute changes to your pipeline.
This completes the setup of your pipeline, the end result is going to look something like this.
If you already have a Gearset Pipeline:
Adding configuration data to an existing Gearset Pipeline comes with a few considerations that should be factored into your planning.
Is this a totally new implementation of Salesforce CPQ or Agentforce Revenue Management?
In which case you might want to build your changes in an isolated Long Term Project for a while before bringing them into your 'business as usual' pipeline.
As with all things DevOps, regular incremental changes are key, so you should be pulling changes from your project semi-regularly. We find that a modular approach to building out a new implementation works best, roughly following the hierarchy of Product Catalogue Management -> Pricing -> Further customisation, which will be familiar to those who've worked in the ARM space before.
Is this a new implementation of Agentforce Revenue Management, replacing an existing Salesforce CPQ implementation?
If so the most crucial step to invest in is planning. Regardless of the path you take to implementation you will need to account for the extensions that have already been made to your CPQ implementation, and the processes and automation that have been built on top of it.
If you're planning to remove your Salesforce CPQ solution and replace it within the same set of orgs, you will need to account for all of the existing configuration that currently references your CPQ configuration and it's extensions. Use Org Intelligence to interrogate the current state of your org, and understand the implications of removing that existing configuration.
If you're planning to create an entirely new 'greenfield' org you will similarly need to interrogate the function of your existing implementation using Org Intelligence. Many teams using Salesforce CPQ have built their own custom solutions to problems that Agentforce Revenue Management solves 'out of the box', understanding that existing configuration will help you find the equivalent standard feature in ARM and implement it.
Is this an existing implementation of Salesforce CPQ or Agentforce Revenue Management (deployed to Production, and in use) that you would like to begin deploying via your existing Pipeline?
Assuming that your external ids are aligned (if they're not, use the sandbox refresh method, or the alignment template) you will need to add the configuration data to your repository, and update the static environments in your pipeline to deploy the configuration data.
If you update your existing Pipeline filter without recreating the static environments, the first run after the change will attempt to deploy all ARM items added to repo as these will be picked up as 'new components' to deploy. This could be problematic if, for example, the version of a component committed to the repo overwrites an updated version in the sandboxes.
You may not want this to happen, which is why we recommend creating new static environments when you update an existing pipeline to deploy ARM configuration data.
Step 1 - Remove the existing static environments from your Pipeline
As above, we recommend doing this because if you update your existing Pipeline filter without recreating the static environments, the first run after the change will attempt to deploy all ARM items added to repo as these will be picked up as 'new components' to deploy.
You may not want this to happen, as the components committed to source control from Production could overwrite newer versions in your sandboxes, which you may want to avoid.
This may not be a concern if you have recent used a sandbox refresh to align your environments and therefore all the components are already the same- discuss with your Gearset success manager the right method for your team to use.
Step 2 - Commit the ARM config data that you want to be added to your main branch
Open a new feature branch, and commit the config data that you want to source control. Open a pull request to the main branch, and merge the pull request to the main branch.
Tip: You may want to limit the size of ARM configuration data in your repository below 1GB. Typically, this would correspond to an upper limit of approx. 1 million pricebook entries, or around 20,000-30,000 products.
Step 3 - Open pull requests from your feature branch to your existing environment branches
Open a pull request from your feature branch to the other environment branches, ordinarily we would use a "sync PR" to do this, in this case we're performing a similar function manually.
Step 4 - Create a new pipeline filter
Add the config data that you wish to source control to your existing custom filter that you use for your pipeline, save the filter so that all of your static environments will now use this filter.
Note: For Salesforce CPQ, ensure you also have the SBQQ CPQ managed package selected in the right hand side of your metadata filter.
Step 5 - Re-create your static environments, with the same environment branches
Create the static environment for your Production org, using the new filter, and duplicate it to recreate your other static environments, making sure to use the same base branches as were in use originally. This makes sure that any "in-flight" pull requests remain in your pipeline.
Considerations for the deployment of configuration data
Although Gearset will for the most part treat configuration data in the same way as metadata, allowing it to be source controlled and subject to dependency analysis, there are some key differences in the way it is treated in Pipelines to account for the fundamental differences between the configuration data and actual metadata.
Pull request Validations
Validations will be run on metadata in a pull request (PR), but not on the ARM configuration data, as the metadata API cannot be used to validate data deployments. If the metadata passes validation, the PR can be merged and deployment started, but if there are issues with the Revenue Cloud deployment, this may cause the deployment to be only partially successful.
Partially successful deployment due to ARM deployment failure
If an ARM deployment fails to deploy some configuration data, this status is shown in the Pipelines UI for the deployment. Any errors here can then be found and remedied as needed.
If a deployment has only partially succeeded Gearset will display an error message next to the records that have failed to deploy, along with an annotation to help the user understand the error and resolve it.
Adding new fields to ARM records
When you update the metadata of your ARM objects (for example, adding a new field to the Product2 object) this will also update all of the records stored on that object, as they now have a new field.
If you add a new field to a single ARM record (for example a Product) then Gearset will add this new field to all of your ARM Products in order to keep them in sync. This may show in the CI Job History as a deployment of many more ARM components than is expected, but this is a required step by Gearset to keep your environments and orgs up to date.
Gearset will add this new field as empty so that it doesn't affect the org and these additions will not show in the git commit history of the PR.
Call for feedback
We're always eager to hear user feedback, and to understand how we can best support your team. Please get in touch over the in-app chat if you have any questions or feedback for us!