Description
In this video, we’ll show you how to deploy CPQ configuration data and metadata together with Gearset.
- Step 1: Before running your first CPQ deployment, navigate to the Salesforce orgs tab and use Gearset’s one-click wizard to configure Gearset external IDs to your records. This setup only needs to be configured once, and does not need to be repeated with each deployment.
- Step 2: Select your source and target for your deployment then configure your filter for the metadata and CPQ config you’re interested in. Use a SOQL query to focus on specific records.
- Step 3: Run the comparison and browse the side-by-side diff viewer to select the items you want to include in the deployment package.
- Step 4: Action any suggested fixes from Gearset’s problem analysers with just a click, to increase the likelihood of deployment success.
- Step 5: On the deployment summary page, add a deployment name, notes and any associated ticket before deploying your metadata and CPQ config package.
Find out more:
Transcript
Hello. My name's Tom Devernon, a CPU cell specialist here at Giersab. Today, I'm going to be walking you through a CPU deployment solution, to show how gear set can now handle those notoriously, challenging, and often manual CPU configuration deployments.
Before we get into the app, just wanna highlight my email address, just here. If you'd like to hear any more information about the solution, or even trial it out, feel free to drop me an email.
Let's go ahead and get into the solution.
Now, before we jump into the demo, just a couple of points wanted to highlight.
Gayset can now handle your CPQ config data and metadata deployments together under one deployment.
Gone of the days of having to separate out your config data and metadata deployments.
Gizz is also going to treat your config data exactly like we would metadata, where we're going to break down any dependencies and related objects.
Let's jump in then. First things first, when it's getting started with the solution, is to head down to the my connections tab where we have our sales resource connected.
Today, I'm gonna be using tools in the demo, my CPU source org, and a CPQ target org.
I can expand this out to see that gear sets added a CPU external ID setup wizard.
And essentially what this does is takes all of your CPU objects At the point of this deployment, we're gonna add a custom field called Gear external ID to all of your records. We're gonna populate that with the external ID, which is essentially the Salesforce record ID flipped in reverse.
This is what allows us to match those records off within a source and target, and ultimately allows us to compare and deploy CPQ config data between your environments.
We recommend running this on production, then completing a full refresh, that way all of your Salesforce record IDs, and therefore external IDs are going to be aligned.
Any configuration built after the external ID has been set up will be treated with a virtual external ID, so this is considered a very much a one time setup.
So once that's completed, I'm then gonna head back to my metadata compare and deploy page, where I'm gonna go ahead and select my source org, which in this case is my CPU source and my target org, in this case my CPU target.
Before I go ahead and run my comparison, We've got some filters here, some standard metadata filters, and also some prebuilt CPU filters.
We always recommend to build out your own custom filters, and you can see here that I've included four metadata types, and also forty nine CPQ objects within my filter there.
Heading to the CPQ filter, I've selected all objects here, and you can see the list of objects broken down.
If you are working with advance approvals, you can also include those, and as well billing.
We've added a so called query filtering system here, so you can really pinpoint it exactly what records you're looking to compare and deploy against.
For example, today I'm gonna be highlighting in the in the deployment a super car product, so I can write a simple query, name, super car.
I can test that query, and guess it's gonna pick up that there's one matching record within my source.
Once I've built out my filter, I'm ready to go ahead and compare.
Here's this thing gonna highlight any new items, So things that exist within my source, but not my target.
Any changed items, things that exist within source and target, but there's just some sort of difference.
Now, I'm ready to build out my deployment.
I've got some Apex classes, so as mentioned, we can now combine both metadata and config data deployments together, so I'm gonna go ahead and select these Apex classes with the relevant permissions as well.
I'm also gonna scroll down to the super car example that I mentioned, the CPU product here, and go ahead and select that there.
Heading to my selected items tab, just to show you how we are breaking down those records to show any related items or dependencies, I'm going to expand this Chevron here on my CPU product, showing independencies, in this case, we've got a custom object with no difference, so that's fine. Also gonna highlight those related objects. In this case, I've got some CPU product options, product features, price book entries, configuration attributes, and a configuration rule.
Again, I can expand this out further to see those individual records. So in this case, with my supercar, I've got some luxury interior, michelin tires, and I can select those components as needed.
As this is a new item, I may well have a product bundle that I'm looking to deploy. In that case, I can select related, and that's gonna pull the product bundle through for me.
In this scenario, I'm just gonna include my product options.
So that's for your new items. For changed items, very similar, where I've got my CPU product, this time a four K video camera, Guis is gonna tell me that there's a difference, when that change was made, and who by. And I can also see below in the JSON, what that change actually is. So in this case, I've added a product description here, product or cell, exclusive of Black Friday, and if I go ahead and select this, This is what I'll be deploying to that target org.
Again, I could also expand this out and see those individual records as well. Again, I've added some differences here on each record, and we can see the JSON on what that change has been made.
So once I've selected all my changes, I'm ready to move forward.
At this stage, we're gonna run our problem analyzers on the deployment package.
This is gonna pick up any issues with the deployment package Ultimately, things suggest to fix this here. Missing dependencies is a key one.
Also any mesh data that needs to be included within my deployment for that to be successful. Yes. It's gonna pick up on these and include these for me.
The final stage here is the summary of items to deploy.
Now I can give my deployment a friendly name, let's say, CPU deployment super car, added some friendly notes, added SuperCar.
I can update my Jira ticket, Asana, or work items here. See if I search on my project.
I can update this Jira ticket as needed.
And then before we go ahead and deploy, it's worth noting here that we've broke the deployment into two, so I've got my metadata listed here. And then I've also got a list of my config data.
At the point of deployment, we're first gonna deploy the metadata, if that goes through successfully, we're then gonna attempt to deploy the concentrator.
Once that deploy has been completed, that is gonna live in my deployment history tab here where we do have the ability to roll back any changes made to your configuration data.
That's very much it for the demo. If you'd like to hear more, or even trial the solution, feel free to reach out to me again at this email address. Be more than happy to arrange it on the demo or add a trial period to your account.
