Description
Salesforce CPQ deployments are known for being slow, difficult and error-prone — but Gearset’s new solution for CPQ offers a fundamentally different approach that makes the pain of CPQ a thing of the past.
Catch up on this session recording from the Gearset DevOps Summit 2022 with Stephen Chambers, Head of Product Design at Gearset. Stephen covers the challenges of CPQ deployments and the impact this has on teams, including:
- The creation and maintenance of external IDs
- Dependencies and the complexity of the CPQ data model
- Coordinating Salesforce metadata and CPQ deployments
- Lack of a reliable DevOps process
- And how Gearset offers a simpler way to deploy your CPQ configuration.
Related videos:
Learn more:
Transcript
Thanks very much. So thanks everyone for joining. And today, I'll be talking about how to deploy your CPQ config, in a much simpler way, hopefully. So as a little bit of background, I've spent the last fifteen months speaking to a variety of Salesforce professionals who are actively involved in the regular deployment of CPQ configuration.
It didn't take many conversations before it quickly became apparent that irrespective of a person's experience or their role, managing CPQ deployments was extremely challenging for teams of all shapes and sizes.
Conversations I was having felt more like therapy sessions for a lot of users and began to resemble the five stages of grief that ranged from denial, it can't be this difficult. I must be doing something wrong. To anger, I'm going to throw this laptop out the window if I don't get these product bundles deployed.
To bargaining, please let this deployment work. I swear I'll do it properly next time.
The depression, I can't take it anymore. I never want to see another spreadsheet or product bundle ever again. And finally, acceptance. This is my life now, and I just need to get through every sprint when we're deploying CPQ.
The challenges that teams face when it comes to deploying CPQ often leads to increased preparation time, deployment complexity, and increased costs both in terms of time and money.
A simple typo or a misconfigured data load from a sandbox to production can lead to deployment nightmares. It leaves little room for error.
It's certainly more stressful if you only have a small deployment window in which to get your changes live.
The question now is why are CPQ deployments so difficult?
Well, I've taken all of the feedback from the teams I've spoken to for the last year and condensed it down to the four biggest challenges that they've told me that makes, that prevents their CPQ deployments from being fast, easy, repeatable, and error free. I'm sure anyone who's watching this who's actively involved in deploying CPQ will recognize these challenges and probably have their own stories to share.
So challenge number one, the creation and maintenance of external IDs.
When deploying CPQ records from your development sandboxes to production, all of the Salesforce record IDs will have changed. The most common approach to tracking CPQ records in order to work around this complexity is via the use of external IDs.
This means that additional setup steps are required even bore even before you can think of making changes to prevent the deployment of duplicates as well as knowing which records are new, changed, or deleted.
You need to create and populate external IDs on the various CPQ and related objects, adding more complexity, and eating into the time spent not deploying.
It often means using numerous spreadsheets and data loads to help track CPQ records, a manual task that introduces more errors.
During one large CPQ migration project, the customer told me that they realized it would be four times quicker simply to divide up the work between their colleagues to move the changes manually rather than rely on data loads.
Challenge number two, dependencies and the complexity of the CPQ data model.
Due to the abundance of configuration options built into CPQ, the underlying relationships between all the objects has also led to huge complexity when it comes to understanding and making changes at deployment time.
When I say complex, I mean really complex.
This is the CPQ data model from a couple of years ago, and it has grown since then.
There's a supercomputer at NASA still trying to figure out the rest.
And some of the objects even reference themselves, so you end up going around in circles.
To make matters worse, if you didn't think that was even possible, you may also have advanced approvals and or billing to contend with just to add two additional cherries on top. The lack of transparency and understanding of the complex relationships between objects often feels like the proverbial black box.
Want to deploy twenty new product bundles?
Are you sure you've included all the necessary product options, features, costs, configuration rules with all of the exact configuration you intended?
Probably not.
Challenge number three, coordinating Salesforce metadata and CPQ deployments.
CPQ configuration deployments do not happen in isolation.
These changes often have dependencies on your Salesforce metadata also being in a particular state.
For example, specific pick list values being present that your CPQ changes have a dependency on.
If they don't exist, your deployment is already doomed.
What this means for teams is that deploying CPQ configuration requires the careful planning and coordination of two Salesforce deployments instead of just one. You'll need to prepare and successfully deploy all of your metadata changes, followed down by the preparation and execution of a second deployment to promote your CPQ changes.
Last but not least, challenge number four, the lack of a reliable DevOps process.
So the combination of all of the prior challenges means that integration into a typical DevOps release process often isn't possible.
If most of your CPQ changes are made manually, then integration into an existing and well defined process leads to an overhead that didn't exist before.
I was told multiple times during my conversations with users that they resort to sitting with two browser tabs open next to one another and manually copying across the configuration.
I'm willing to bet that situation resonates with a few people in the audience here today.
There's often no easy way to standardize on changes and track them as they move downstream.
This is knock on effects, such as limiting your ability to have a history of changes for auditing purposes or identifying changes that perhaps weren't intended.
The real world consequences of deploying CPQ configuration incorrectly can be extremely serious.
You may find that you've misconfigured quotes have led to the overcharging of customers, and the resulting negative impact on your business's reputation could be catastrophic.
So in October of last year, the GearSat team sat down and thought about how we could solve those problems. We need a way to easily visualize CPQ configuration differences between orgs and all of their dependencies, handle the complexity of creating and maintaining external ID records for users, allow the deployment of CPQ alongside metadata in a single deployment, and create a history of deployments to enable easy tracking of changes.
So as luck would have it, Gearset already does that for Salesforce metadata.
So we thought, why don't we simply treat CPQ configuration in exactly the same way that we treat metadata?
Might not take eight years of experience of deploying Salesforce metadata and apply those same principles and add new dedicated features to deploying CPQ.
And that's exactly what we've built, and that's what I'd like to share with you now.
So in the interest of time, I've already run the new gearset external ID setup process on my source and target orgs and run a comparison.
So for anyone who, is isn't familiar with gear set already, when we compare, the source and target, we break the comparison results into a couple of defined categories.
We change, we put our, changes into new items. So those are changes which exist only in the source, but not yet on the target.
Changed items, which are items that exist in both, but, there's a difference in, the XML, and also then deleted items.
And those are items which exist, only in the target and no longer in the source.
So I'm just gonna focus here on, the new items.
Here you can see two custom fields, discount percentage and discount rate.
But also now you've you notice the prefix for CPQ is included, in the comparison results.
When I said that we wanted to treat CPQ configuration just like metadata, this is what we meant. You can easily switch between Salesforce metadata or CPQ configuration in one simple view.
There's obviously a lot of configuration, content possible. So you might want to actually, either include or exclude certain items, to help with filtering.
We have all of the product options between my orgs.
If I scroll down further here, you can also see product features.
And here, because I've run the setup process previously, here you can see the gear set external ID field that was added and the external, the record ID as well.
We also then have, obviously, our CPQ products, And you can see the full rendering in JSON then of the properties, for that.
So I think this transparency is something that definitely doesn't really exist in any other products at the moment.
So let's see if we wanted to deploy a new product bundle.
Since it's, close to Christmas, I want a new laptop.
And here we can see the CPQ product for this new laptop.
If I expand this time oh, just doing away here. If I expand this time, you'll see, that there is depends on, which I can click, and there's a dependency on product two, which exists, in both, and there's no difference, so I don't need to worry about that.
Here, you can see the clear grouping underneath, CPU products of the product options, listed here.
And, I have my product features as well, my price book entry for this laptop with unit price and so on, and cost.
So this provides a really clear, nice, and easy way in which to, see the differences in your CPQ configuration, lets you easily deploy, all of the items in a single, click. You can also actually deselect. If you don't want to, deploy all of these product options in one go, you can just then deselect the ones that you don't want to deploy at this time. It's entirely up to you.
I did mention that you could also deploy, metadata and CPQ in the same deployment.
So let me just include two custom fields in order to show you how that works.
Gear set understands metadata incredibly well by breaking it into its constituent parts and understanding the relationship between those. Here you can see that we've detected that there is a dependency on this discount rate field also being included in order for the deployment to work.
So I'll just include that as well.
If I just click next, Gearset has a series of problem analyzers, which look at the contents of the package that you're going to deploy and cross checks it against the list of heuristics that we have, which we know can cause deployments to fail.
This has existed in GearSat for years now for metadata.
We've also started to, create those same problem analyzers for CPQ configuration.
So here you can see by deploying the laptop, we've actually detected that there are missing components.
So product options and products that also need to be included in order for the laptop to be deployed successfully.
This understanding of relationships between all of these items is something that can lead to a much, much better chance of your deployment just working.
If If I go to my pre deployment summary page, here you can see the breakdown of the metadata items that I want to deploy followed then by the CPQ configuration, which includes the original product and product options that I selected plus those brought in by the problem analyzer.
All deployments are tracked, in gear set. So if you want to just give it a friendly name, you can put that in there.
Deployment notes, if you're working with colleagues on getting your deployments ready and, as I say, coordinating with the other members in your team, you can add deployment notes. We'll generate a deployment report for all of the deployments.
If you do have Jira, you can also attach Jira tickets, to your deployments. They'll also help with the organization of your deployments within your team.
And once we're ready, we'll hit deploy, and GearSat will now perform two deployments.
We'll, first of all, take the metadata that's been included and deploy it, as part of, the first stage of the deployment.
If that works, then the second stage then goes to then deploying your CPQ configuration.
So if the metadata deployment fails, we roll back, to the previous state as we do at the moment, and so your target org, isn't affected in any way. And as long as that deployment then succeeds, and if the demo gods are with me, then the CPQ config deployment will then kick in after that, and we should have a successful deployment.
So here you can see the metadata that we deployed, my two custom fields, and you can also see the list of CPQ products, product options, costs, and other configuration that was also, included.
If you want to jump directly to the record on the target, simply click here.
And if I go to my deployment history, you can see here that, it's been recorded, in there with the date and time stamp. If you want to download the report, just simply click there. We also have two other features that could be really helpful for users. One is deploy to target, and one is clone package.
Both of these, in a way, do the same thing, but slightly differently. Deploy to target will take all of the changes that are in that package, and you pick a new target and deploy immediately to it. Or you can use clone package where you can pick a different source and target and apply the deployment package that was just used to select the same changes, which means that you can repeat the deployment very easily as you migrate changes, along your pipeline.
K.
So I hope you agree that is a simpler way to deploy, your CPQ configuration.
The things I haven't shown you because of time really is we built a completely new, external ID setup wizard, that you only have to run once on the orgs.
I have a screenshot here. You simply tell us which org you want, to run the setup process on, and you click create. And Gearset will do the rest. It'll add the GearSight external ID field to all of these objects, and it'll then populate those record IDs, with essentially, derived from the existing Salesforce record ID just flipped around.
Other features that, are also included is that you can roll back changed, CPQ configuration. So if you've done a deployment and realize some some of it wasn't correct, you can roll those changes back if they've already existed in both.
We have a change monitoring feature, which, takes snapshots of your metadata every day and alerts you to changes. We've integrated, CPQ configuration, into our change monitoring jobs. So you can simply set that up in your org and get alerted if anyone changes CPQ configuration directly in your production org, for example.
We already support billing, at the moment, and advanced approvals is currently being worked on and, hopefully, will be live as part of, GA.
The road map for twenty twenty three, well, we're not sure yet, and that's where we would like you to get in touch, get involved, and help shape us, help shape what comes next with the product. But first of all, GA is December seventh.
It's free to try. If you're already a Gearset user, just enable it via the pilot features in your account. If you haven't used Gearset before, create an account, and start deploying your CPQ config.
Thanks very much.
