Webinar: Mastering CPQ deployments with Cloud Giants: live demo

Share with

Description

CPQ deployments can take hours and can be a real headache. Deepak Veera and Grant Mangum from Cloud Giants, have led dozens of CPQ implementation projects. Grant and Deepak do a live demonstration of how they do CPQ deployments with and without a DevOps tool. This webinar is for you if you’re a Salesforce Architect, Manager, Admin, Developer, or CPQ Config Engineer.

In this webinar you’ll see:

  • What the biggest CPQ deployment challenges are
  • How to deploy CPQ without a DevOps tool
  • What deploying with a DevOps tool looks like

Learn more:

Related videos:

Transcript

Thank you all for for joining us today.

Our topic of discussion over the next hour with our webinar here is going to be CPQ.

More specifically mastering CPQ deployments with Cloud Giants's live demo. I really wanna take this opportunity to introduce to you all our partners at cloud giants.

Cloud giants has been a Salesforce consulting partner since two thousand fourteen.

Their specialty within the Salesforce ecosystem lies within the CPQ and revenue cloud products.

For some stats, seventy five plus successful CPQ projects and implementations.

They have a ninety plus net promoter score and a five star app exchange rating But at this time, that's that's quite enough for me. So I'd love to give the floor over to Grant. So Grant take it away.

Thanks, Andrew.

Hello, everyone. I am Graham Mangum. I am a technical Solton at cloud giants. I've been working with Salesforce and CPQ for over six years now.

I've been a part of many, the building of many CPQ solutions and many CPQ deployments I also managed DevOps for the consulting team at cloud giants.

Deepak Vira. Thanks for joining everyone. Thanks for show Andrew as well for for team is up here. Similar to Grant, I have been doing Salesforce for roughly the last seven years.

I think ever since the advent of Salesforce CPQ, roughly twenty nineteen, or I think when it took off. I've been focused on that space. Focus before that work on other CPQ and billing platforms. But like I said, last few years, been heavily focused on the CVQ and revenue cloud space.

K. So let me tee us off. Of course, the main reason for our webinar the live demo that Grant will be doing here for for all of us. But before that, I'm gonna do a few things sort of tee us up for that.

So let's start with the objectives high level what you're hoping to gain, you know, what is the purpose of this? Why are we even having this webinar? So to to start off with, I wanted to mention, you know, What are some of our attendees? What are the backgrounds?

How will you benefit? Who will benefit? I recognize some names from last time. Thanks for joining us again.

This really is comes out of feedback from our participants saying that a live demo would be really helpful. So we're excited to do that here for you. But also if you're the first time attendee, I think you'll still find this helpful. We'll do a quick recap.

But regardless of your role, developer, or CPU admin, or just new to CPQ in Salesforce. I wanna check it out. I think you will walk away with with some meaningful actionable items, that might be helpful for you or your role in at your company.

What do you have to gain? Specifically, we will do a demo, but in doing so, we will also show an end to end dev ops process. So this is something we use here at cloud giants as Grant and I mentioned before, and you'll hear again, this isn't a one size fits all. We wanna provide a framework, at least a platform that'll inform your understanding, and that it can build and tailor to your particular org's needs. So, we'll talk about, you know, the the the what a sprint might look like, look like whether you're doing build We'll talk about the deployment process itself and also post deployment steps, as a whole.

And lastly, live demo, right? It's, that's why we're here. I think it's always helpful more than simply visualizing to walk through an actual process Grant's gonna lead that portion of it, and we'll spend our majority of our time, there on this call.

Before we dive in though, I do wanna provide some context, some items that we covered last time, but also some items that'll tee us up for our live demo portion here. So in July's webinar, we covered a few things. These should look familiar for those that attended. If not, no worries, we'll go through these again here.

But three items to call out. One, I wanna talk about the challenge of CPQ. Again, like I said before, why does this so different. We're talking about dev ops and we're familiar with dev ops processes.

Why is CPU dev ops in itself worthwhile talking about? So we'll cover that here in a second. Second, we talked about documentation standardization.

I'll call out to you specifically that we will use here, during our live demo. Something we also use a cloud giant. So I'll I'll T Up brand for that. And lastly, I wanna mention the benefits of a DevOps tool. It is possible to do a CPQ deployment without a DevOps tool. Grant will show us that, but it is way easier and way less painful if you have a a CPU dev ops tool.

So let's get into each one of these what makes CPU deployments challenging.

Right? So for those that are familiar with CPU, you probably know this well. For those that are new, let me walk us through this. One, fundamentally, CPU configurations exist as record level data. So when you're configuring a product, if it's a price jeweler product rule, which is the engine behind CPQ.

This is record level data in the eyes of the of Salesforce.

But behind the scenes, it does a lot more and drives very key functionality.

So to that end, it looks like an account or contact, but these are very pivotal code like, records that need to be deployed. But with that comes pain points, we cannot deploy records, as you all know, with change sets.

Now to layering on top of it with record level data, I mentioned my account and contact example, but it's way more intricate with with Salesforce architecture There's a lot of dependencies. So with price rule, you would have a a price condition, price action that goes with it. You cannot deploy a price action or a price condition before deploying a price rule. So just like any other data deployment, you have to be very mindful of layering, records in the correct sequence, which is, can be very painful of course.

Lastly, I think to make matters worse or more complicated.

It's not just records, but these records also have metadata dependencies.

So fundamentally, I'll come back to my price for example. We may need to create a a price action that updates a certain field. Now that field would mean to do that, we would go in and we would add that particular pick list value to CPQ's managed package field. Now with chain sets, we cannot deploy managed package field components. So that in itself makes things complicated But again, the call out here is there's a lot of dependencies, and these dependencies also have metadata dependencies.

So it makes CP quite complicated to work with.

But let me pause there.

I wanna get some feedback from the audience. I'm curious to see if these resonate with you. Particularly what other, items have you experienced that have made CP deployments challenging for you in the past? So please feel free to to, comment you in the chat.

Hey.

Yeah. And again, just, we encourage some, you know, engagement in the chat. So we got first one from Steve. They always involve a lot of records and components.

Any other thoughts from the group on if these resonate well, Ted, thanks for the comment. You've hit on the key issues. It is more of a data migration in many ways. Rachel, all the dependencies between objects, of course, a big one there.

Yeah. Absolutely. I think we see, kind of the the same issues, using custom condition. That's an excellent call out.

There's particularly nuanced with CPQ are mentioned, deploying price rules, but you cannot deploy price rules with a cut some condition or advanced condition. You have to toggle it back and forth. There's tons of dependencies, and it is hard for somebody that's new to come in without knowing that to know exactly what needs be done. It is not your own a deployment.

K. Man, let's go to the next slide.

Documentation, for those that are studious and taking notes here, I would make note of these two items, but if not, you know, we'll come back to it, of course, There's two that I wanna call out that Grant will cover, and these are ones that I mentioned earlier, a change log and, just a deployment script.

For us having done countless deployments, having done many CPG projects, we work with, you know, we work with our colleagues to sell them just one person that's deploying. But even if so, logging your components during a sprint is extremely helpful to make sure you've captured everything. DevOps tools help with that. But particularly if you're working with multiple people, if you're working working across multiple work streams, you need a central place where you're logging to make sure that you capture all those items. It changed August what we call it here. It goes by other names, but the concept is the same. Again, Grant will go over that here in a second.

The next item is the deployment script Right. Nothing too fancy here. Just to call out to say, not everything can be captured in a deployment Right? Whether you need to install packages, whether you need to run post install test scripts, or whether you need to do some sort of smoke testing, is simply a checklist to make sure that our deployments are thorough. So again, just to just keep these in mind, we'll see those, in our live demo example or live demo in a second.

K.

Just to round out the the recap portion, I wanted to highlight why CPU dev ops tools have been really helpful for us here at cloud giants. The the main value adds is I mentioned that CPU configuration exists as data.

In the UI, in the dev ops tool, like what we see here with gear set, it shows, CPQ data configurations with its metadata as well. So a single stop where it's visualized the same is treated the same with the dependencies, it's really helpful. Again deploying CPU data with and as metadata is accelerates our process, significantly.

Second, a small but meaningful call out though is with, gear sets tool, we can indeed deploy things like those pesky price action, tested field values. Right? Where with it already changed, so we cannot do that, that would have to be something you do as a manual pre deployment step. Here, we have the ability to deploy managed package pickless fields as well. So all these are big time savers.

Grant, we'll cover those here in a second.

But without further ado, I will turn it over to Grant, who'll walk us through a a live demo of this.

Alright. Thanks, Deepak.

So to sort of set the scene for our demo today. Well first, let's go over the agenda. Today, the structure of our agenda will kind of look like this.

It'll be broken into two parts.

One, where we talk about a deployment, what it looks like, without gear set from a more manual CPQ deployment standpoint, and then we'll look at the same deployment, but through the lens of using gear set.

Start us out though. I wanna set the scene.

This may be relatable to many people here who have been involved in a CPQ deployment.

But really, Let's say that, it's a Friday Deepak and I have been working on some business requests related to CPQ and we've finally gotten to the point where we're ready to deploy those changes.

For the sake of time, gone ahead and built out a few things that we will be moving from our sandbox environment to production.

So I'll highlight those things here.

One, we have two bundles that'll be getting deployed. You can see here, we have a product record that we want to deploy, and that product has related CPQ records, it has features that will need to be moved from our source environment to our target environment. It has product options that will need to be moved and each of those options have a related product that will have to move.

And we have price book entries. We have a price book entry here on the bundle parent product, and each of the child, bundle child products will have a price book entry as well. This is sort of our product data that we'll have to migrate from our sandbox environment into production.

We also have a product rule that needs to move. The product rule is going to have a related error condition record that we need, as well as a product action record. I don't need to move from Sandbox to production as well. We have price rolls.

This is yet another object that is going to be moving from one org to the next.

It's, the price rules have a related price condition record that needs to move as well as a related price action.

So that is all of our CPQ data that's going to be moving.

On top of the CPQ data, as Deepak mentioned, there's often metadata that's going to be included in a deployment.

In the case of this deployment, we have manage package metadata that needs to move Deepak hinted at it earlier.

This field on price condition called field. This is a managed package field, and it's pick list values need to move to production as well so that we can correctly configure our price rules.

Same with price action, the target field, managed package field, we'll need to have its pick list values moved as well, same with our product rule. The air condition has a similar type of field where we need our our pick list values moved as well.

And then for good measure, you know, it's not just, managed package metadata items that need to be included in deployment. Oftentimes, we have other things that are metadata that needs to move as well. And so we are also gonna be deploying this page layout that I'm showing here, and action on the page layout as well as a flow.

So we have kind of a combination of both CPQ data, our CPQ managed package metadata, and then custom metadata that we've built.

That really gives us the full scope of what our deployment will look like. So first, like I mentioned, we're gonna talk about a deployment without gear set. So Here on the screen, you'll see illustrated what a DevOps and deployment process without gear set could look like.

It's kind of broken into three phases.

There's our configuration phase. We'll dive deeper into each of these in just a minute. Our deployment phase and then finally our review phase.

Starting with the configuration phase, just as what it sounds like. This is really where we are working together Deepak and I in our sandbox environment, building solutions based on the requirements that we've gathered.

As we're building though, we are also building out the documentation that's going to aid us in our deployment as well. So here I'll show you DeepOC mentioned, a change log and pre and post deployment steps, let's look at what those look like. Here I'm showing what the component list in a change log could look like. As we're building, we would be populating this document with each of the items that we wanna move from our sandbox environment to the next environment, whether that be another sandbox or production.

And we're capturing both the metadata that needs to move as well as the CPQ data. Reason we're capturing it here is because oftentimes we aren't working together building a singular, you know, deployment package. We're kind of co developing, and then we're gonna be moving all of this work into the next environment at the same time.

So we're capturing here to help us organize and make sure that we've captured everything that we know is going to need to move, to the next environment that we're gonna be deploying to.

I'm just a couple of things. If you don't mind, I wanted to point out here because I know we had some questions from this last time. This is something we create internally. It's nothing fancy. This is works for us.

For both grant and myself, we are we wanna make this accessible to people. So meaning, we don't wanna pay so much overhead that it would dissuades people from logging items in here. So simplify best you can make sure everything else is is necessary.

But I only say that because I know for me, it is there's a tendency where we tend to over engineer processes because we wanna be so, you know, we wanna make sure that we're protecting and mitigating risk. But I'll on the front end too, we wanna make this easier for So just to call out, simplify where you can with a change log if you're, you know, looking at this and seeing what you can do with it.

Definitely.

So, you know, maybe some of these columns that we're capturing here would be helpful for your process. Maybe not.

But yeah, simplicity, oftentimes should win out.

As we're As we're building, as we're populating the change log in our component list, we're also gonna be capturing any pre and post deployment steps that we know are going to need to happen.

This is what, the pre and post deployment steps for a deployment of this size would look like. I'd say this is a pretty realistic, the steps you would need to take in order to deploy all of the items that were mentioned without gear set. So a few things that I wanna highlight here.

Here you can see I captured those custom or those managed package metadata changes that we're gonna have to manually make. I captured those here in our pre and post deployment step list. Those aren't changes like Deepak mentioned earlier that we can deploy through change sets.

If we don't have a tool that can help us do that, gonna be manual things that we have to do.

Along along with that, I've also included here those manual data migration type steps that you're gonna have to take as well to move your CPQ data from the sandbox to the, to production.

In our pre deployment steps, I have export of those of that data listed out in each of the objects that we know will need to export based on what it is we've built. And then in the post deployment steps, you'll see the steps of one, importing the data, but then also the extra steps that you have to take based on, you know, maybe external IDs or whatever to do those v lookups to make sure that everything is related the way that you would need it to be.

This is what those steps would look like.

And I noticed he correctly gave me the easiest step in this deployment?

Yes.

Yeah. So I feel everything else. Good call.

Alright. So that's our configuration phase.

Let's transition now and talk about what the deployment phase would look like. This is where maybe the meat of the activity that has to happen is going to be. So first off, we recorded our pre deployment steps and those steps that we're taking to, export the CPQ data that we need. Are the first things we're gonna do. We're gonna make sure that, all of these items are completed in our production environment And as we go, you know, we may want to check them off so that we know that they've been done.

Just for the sake of simplicity, you can think of these things as separate items, but they kinda happen at the same time. For the sake of simplicity, we've included them together in our pre and post deployment step list.

Once your pre deployment steps are complete, that's the point in which you can deploy those metadata changes. So in the case of our deployment, that would be the flow, the page layout, and that action that we have on the page layout. We would do that maybe with a change set and deploy that metadata from our sandbox environment into production.

And then we would begin tackling our CPQ data migration steps as well as the post deployment steps.

Again, using our our list here as our guide, we would go through step by step doing those things that need to be done that manually need to be done that couldn't be done through our change set.

That brings us to the end of the deployment phase.

Once our deployment is complete, we then move into the review phase. And this is sort of our time to check and make sure that we've crossed our ts and dotted our eyes. So typically, what we would do is review our change log, make sure that all pre and post deployment steps are complete. We haven't missed anything.

And, you know, we may also want to indicate in our change log that the item has been deployed.

And, Now it's no longer an outstanding item that needs to move from our source environment to our target.

And then finally, our last step would be to smoke test. Talked about this in our, first webinar. Smoke testing is particularly important when when you're doing a CPQ deployment, especially when you are doing all of these manual data migration type steps.

It's very easy to accidentally mess up a relationship between two of these objects, you know, maybe you relate your price conditions to the wrong price rule.

Sometimes when you make mistakes like this, that can result in like a complete lockdown of the quote line editor. And when users go into the quote line editor, try and configure quotes, try and save quotes. They get a red error message that blocks them from doing that. And you know, if it's a Friday afternoon, having to address whatever those issues are are just gonna prolong the time it takes for you to go out, meet up with friends, or whatever it is you have planned.

So you wanna find those things early. You wanna address them and hopefully avoid you know, getting pinged by the people in your org telling you that things are broken and they need help.

So What's the what's worse than a deployment that takes a really long time is coming into the office on a Monday and finding out that you broke something which may or may not have happened to me. Can't disclose.

I I wanted to make one call real quick. Grand, start to interact interject it. The the pre deployment post deployment strips where we have all the V lookup IDs.

As we heard from our participants here, like, that is a major pain point, and it's extremely time consuming.

It's fine if it's just few if it's an agile sprint, but in my experience, as as a consultant. We usually are doing sort of we're doing an initial build phase for two or three months. This is a lot of components. It's extremely painstaking to make sure all those correctly, you're they're layered on correctly as well.

Absolutely.

I think now is maybe a good time to pause. I'll turn to the audience and ask the question.

Now that you've heard sort of this process of deploying the CPQ without, gear set, Are there any tips and tricks that you found helpful as you've gone about that?

And feel free to use the chat there to Grant's point. Anything that you guys find helpful with some of these steps that you would be using?

Steve. Thanks for the comment. Using a log is critical. I've forgotten something numerous times.

Rachel, I think you nailed it. That Excel doc is exactly the format of a doc I used at my last org, and I can tell you things got missed and broken. Felix created external IDs on every object to make the migration easier. A great thing there. Rachel, again, it's greenfield work in prod. From the get go.

Makes it a little bit cleaner. I'm sure there. Yeah. Rachel, a good point.

Ted, another, emphasis on smoke testing to Grant's point and to being critical in the grants there.

Great. Yep. Those are all great things. Thanks for the participation, everyone.

Let's now move on and talk about maybe what this process can instead look like.

With the use of gear set.

So here, I I have changed slides. It looks very similar. A few minor changes.

We still have our three phases, our configuration phase, deployment phase, and then again, our review phase. Let's talk about the differences.

So still Deepak and I, we are working together building based on the requirements that we've received. In our sandbox environment.

And as we're going, we are still keeping track of items that we know need to move from one environment to the next.

We're also still capturing pre and post deployment steps.

But because we're using gear set, that list of pre and post deployment steps are going to be significantly smaller.

Here you can see what the steps would look like without, with gear set.

One of the key major differences is that all of the custom, or sorry, manage package metadata.

Those are no longer manual steps that we will need to take. And then all of the CPQ data migration steps, those also are no longer steps that we will manually have to take as part of the deployment. So really, this would be it. And in theory, you could even get rid of this step by toggling on the setting to auto activate flows on deployment. So you greatly minimize the things that you would have to do either before or after you click deploy in gear setup.

So now we've built out our documentation.

Again, it's Friday. Deepak and I are ready to deploy.

So first things first in our deployment phase. Again, we would start with pre deployment steps.

You know, gear set can't magically solve all problems. There may still be some pre deployment steps that need to take place. But like Deepak mentioned earlier, it's gonna be something like installing the CPQ, managed package in your org, things like that. Again, the number of pre deployment steps are going to be greatly reduced.

Once pre deployment steps are done, that's the point where, woops, we start building our gear set package.

So now I'm going to hop over into gear set and we'll take a look at what that looks like.

So here you can see I'm now in the gear set comparison view. What I've done to get here is I've connected my sandbox environment in my production environment.

And I've selected the things that I want to include in a comparison basically the things that I wanna deploy from the sandbox environment to production, and that's given me a list of all items that meet that criteria that I set up.

Here you can see it's included things like CPQ data right here is a CPQ error condition record that it's prompting me to add to a gear set package. There's price actions, price conditions, price rules. All of our CPQ data is showing up here, but at the same time, We can also scroll down and see that metadata is showing up here as well. Here are custom fields. And if you notice here, we have the s b q q double underscore prefix. That's telling us that this is part of the CPQ managed package. This is selectable here for me to include in the managed package or in the deployment package as well.

And then if you keep scrolling, we see our flow down here, our layout. One quick aside, one thing I love about gear set is the ability to partially deploy certain, metadata components, page layouts being one.

You know, maybe multiple people are working on page layouts I can pick and choose the changes on the layout that I want to deploy for one word to the next. So we reduce the risk in that way too of accidental deployment of things that shouldn't be there. That's a bit of a digression.

Let's go back to CPQ here.

Sorry to interrupt. I was gonna take a quick plug and see if we could feature. I think it was Ryan had a question on the change log, and I also just replied to it. I The other item here is that we can search, for anything that is new or changed or is changed by what person which makes it really helpful.

So, right, I hear you on that. I've often thought, you know, with logging components to a change log, I've told, you know, former colleagues. I'm like, I don't trust myself to do it. Don't know if I trust somebody else to make sure they've logged everything to the t.

Right? Which if you're not using a tool like this, you have to. Otherwise, you wouldn't know. But there's been so many times I've come in, you know, caught things that need to be deployed, and I'll add them to the change log just for the sake, you know, for, like, symmetry purposes, making sure we're logging things.

The so I that's one thing I'd call out. It's not clear just because we're using system admin, but in a normal environment, it will show you exactly who made the change if it's new edited or deleted.

Absolutely. And the way that you're able to sort of slice and dice this view is pretty cool.

We have our different columns. As you can see, I can sort by who it is that changed something when it was changed.

We can even filter things out. Like, if I don't want to see any of the air conditions that have been returned. I can remove those from the view and really drill down and find the things that I know I need, but you know, in some cases, there may be times where you don't know what you need. That that may be particularly the case. If you don't have a document that you're sort of using as a guide to build your package, One other really cool feature is, if you look here, there's like this drop down capability.

For the different components and it can show you what other places a particular item where it's being used. So like what's dependent on it, but then you can also see like who's using it as well. And it's just a a further way to go and add things you want to your, your deployment package.

This is a very helpful view. If you compare this to change sets, it's you know, light years better than what you would have available on on that front. And you wouldn't even have, you know, CPQ data available.

Alright.

So we've been building our gear set package.

Sort of in tandem as we're preparing that package and getting ready to click deploy on it.

Gear set has what's known as the problem analyzer. So let's show that. What I'm gonna do so that we can make sure that something is caught is I'm gonna remove this tested or I'm gonna remove the the field field from price action. I know that stuff in this package is dependent on that field being included in deployment, but I'm gonna remove that, which, you know, you probably imagine would cause issues with the deployment.

So what happens before you get to the screen where you can click deploy is gear set runs what's called the problem analyzer to review items that have been selected and added to the gear set package to see if there's any potential issues you know, you may think, well, when I click deploy, Salesforce is going to block me from deploying things if, like, dependencies are missing. Yes. That is true. But oftentimes, the time it takes for the deployment and validation stuff to run is pretty long, and it can be frustrating as you're getting those, like, issues one at a time having to go back and forth and add things. It's not ideal. Which makes this, problem analyzer really nice.

You can it's sort of like a front end check do an initial review to see if there's anything that may cause issues. And if there are things that are found, it'll flag that for you as no items you may wanna include in your deployment. So if you remember on the last screen, I removed this field from the package, but it's realizing based on the other items that I've included that, we may need to include this. So it's prompting me to go ahead and have that added to our deployment package.

This is just sort of another place where gear set helps us avoid errors and kinda save time too. Yeah. I'm gonna nerd out for a second. I think this is really cool.

Just because I get the relationship with with data configuration records, and it's saying there's a particular call out on this record and there's no metadata to match it. You should consider including this field to make this appointment successful. I've been that exact same year before. Right?

So I think catching items like these where there's no way an ordinary, you know, a CPQ or sorry, Salesforce deployment check would would account for this. Right? So, I think these items are quite helpful.

Agreed for sure.

So you reviewed our problem analyzer we found this issue and we're gonna include it. At this point, we're ready to deploy. We go to our pre deployment screen.

We've made it now to this step in the deployment process, deploying our gear set package.

If I come back over here, this is our pre deployment screen, sort of gives us a summary of everything that'll be included in the deployment.

Both the metadata items, but then the CPQ config data items as well.

You do have the ability to connect to whatever, issue tracking tool you use, whether it be Jira or something else to track your deployments there as well.

But then, you know, at this point, we're ready to click employed.

And that brings us, now to our post deployment steps. Once deployment is complete, we've deployed everything to our production org.

Here in the deployment summary within gear set, we can see the metadata items that have been deployed. And again, as well as CPQ config items that have been deployed, something that's cool, as you can even go ahead here and see the Salesforce record ID that's been generated for that item. That's captured here in gear set as well. All of that's complete.

And now if there are any we would complete our post deployment steps.

And that brings us to the end of the deployment phase when we're using Gears Seth.

And finally, we're in our review phase.

Again, back in the change log, we check off any post deployment steps that we've completed.

If, it's part of our process. We can indicate in our change log that we've deployed items. And then again, we do that smoke testing.

You know, some of I mentioned it earlier, but some of the things we really wanna check for, are really in the quote line editor. If I use our flow here to get there, wanna go to the quote line editor and just make sure that we can save quote success that's really the major thing that we want people to be able to do.

So we've already have some stuff here, but I will go and add a product.

We have our our bundle that we sent over.

We see our features and our product options, our of the children in our bundle.

I'm gonna save it.

Things generated here correctly, but then the final step would be just to click save.

And we don't get in the years. We save successfully.

I think at this point, we could officially consider our deployment complete. You know, maybe you need to notify users that the deployment has happened. They can use the system again. You know, that may be part of your process too. But for the most part, all of these steps we've laid out here are finished. So That's what a deployment looks like without gear set and what the same deployment would look like with gear set. As you can see, gear set makes a major difference with CPQ deployments.

Some of the benefits that Deepak and I really love are the increases in time efficiency.

We have more confidence in our deployments.

We know that there's less chance for human error because, gear set is doing a lot of the heavy lifting, which ultimately means that you know, there's less to uncover in our smoke testing, and really all of this leads to much more predictable deployments again, if we go back to that example, it's a Friday. We can go into that deployment on a Friday knowing with with a better idea of how much time is going to take us rather than, you know, we know we're deploying, but we really have no idea where things will go. With gear set, it's much more predictable, which is ideal for us as well.

Awesome. Okay.

Well, alright. Thank you. Deepak and Grant. Lot of great insights in there. And I wanna take a second and just thank everyone for the continued engagement throughout the course of that presentation.

At this point, we're gonna move over into our Q and A session where we can dive a little bit deeper into any of these issues discussed and field some questions. Now I know that there are some that have trickled in. So we're gonna come back, in just a quick second.

For those of you who have to jump, We'll see on the screen here, Grant's gonna show a link out that will allow you to learn a little bit more about cloud giants. Now know there was also some questions, ranged up from you about the documentation that you saw, Grant displaying during this. So in that link that's on the screen, there's a form that you can fill out and request a template if you would like to use some of what they showed in that presentation From there though, we're gonna go ahead and jump into that Q and A. Feel free to type anything new into the chat.

Let's open it up to some questions though. What I wanna start by doing is going back to I think we had the first one I saw that we haven't answered yet is from Felix Phillips. Something that you said earlier that caught my attention, can you deploy flows and auto activate them through gear set? Felix, we have some documentation on the way that gear set it just flows.

So feel free navigate out to our website. You'll find our documentation page, and you'll see some information there. To answer it, just generally speaking, though, Gearset is going to take the status of the flows as they are within the org that you're deploying from. So if that is in a draft status, when upon deployment, you'll see it in drafts.

If it's already active in that source org, it will activate it upon deployment.

Feel free to learn a little bit more about that within our doc site though. Next, let's move over to Montedeep who asked a question about best practices you would suggest for maintaining consistency with external IDs.

I may tap on the shoulder, of Granton Deepak. Did you guys have any thoughts? I'll just kind of start by just saying, we do have the gear set external ID wizard, which is a simple way of being able to populate those orgs in your pipeline with the gear set external IDs. And there's some strategies that we use with our prospects and clients that allow that consistency between the two. Grant and Deepak, did you have anything you wanted to maybe add there that you guys have seen for external ID consistency?

Yeah. I can take that one. We need a chance to go through this in the demo today, but part of the process, like you said, Andrew, is it'll walk you through setup. So it means it auto creates the field and then populates IDs for you, you it also gives you the option of auto creating flows that'll prevent, record duplication.

Right? That's really valuable. So it makes life a lot easier. There's guidance on it too.

Right? Yeah. Thanks, Deepak, for that.

We'll come over then to let's see. Who was next on this? Chris, You had a question about gear set pipelines, metadata deployments.

There are CP configurations available to go through there. Alastair did respond to that that we do have CPQ for source control coming. It's not quite in your set yet, but our development team is is working on that as we speak. And Alice or Ryan, have seen some of the first slices of it, and it looks pretty cool. For the time being, though, it is more of that org to org movement.

Then we go to David, genteel's, or gentlest. Do you have a good strategy for records that have been deleted example, being a price condition in a price roll. It's just that is that just adding to log and being one of the manual steps taken?

Cloud giant's friends, Deepak and Grant. I might I might see how you guys maybe do that today where maybe you have a deleted item. Are you guys typically adding that to your change logs or is there some other way in which you're kind of managing some of those records that have been deleted?

That would be something that, We add to range log. I think the nature of how your set treats data as I understand it, they do not want to be responsible for the deletion of any CPQ data. So if there are things that have been removed from maybe your sandbox environment and you need to deploy that or move that change to production. That would be a manual step that you have to take. You're going to have to delete things.

And so, yes, that would be one of those for your post deployment steps that we would include in in our list of those things. Yeah.

Alright. Also, no, like, we can always deactivate items. Right? So that's deployable.

Just with the I think the dependencies exist. Now the outright deletion of a record is not yet supported in in the gear set. Yeah.

That's ex that's definitely true. An intentional decision up to this point. I know, it's been something that we've been asked about pretty consistently is Hey, can we do deletion changes with CPQ?

We kind of subscribe to this notion of there being some risk associated with deleting data as we know, CPQ data, a little bit more close to metadata. So it's something that we're considering at the moment, but as of now, Deepak's absolutely right on that.

Next one, we'll go over to. Mariela, you asked if you can get a copy of the Google Doc. I saw Christina did respond provide a response. But just for those of you, who may be curious and with the same question, this link that you see Grant's got up on the screen. If you go out there, there's a form there that you can certainly fill out.

Provide your email, and then we'll get some of those templates over to you all if you have interest in potentially using those. Deepak grant, anything to maybe add to that, or or you think kinda covers it.

Yeah. I mean, I I I would say we're we're happy to share. Please get in touch with us through this. Grant and I are on LinkedIn. You know, please reach out to us there too. It's always nice to, you know, work with other CPG people and learn from each other.

Awesome.

Okay.

So let's see where we at next here.

K. Barsha asked a question about Gearsat support Salesforce billing deployments.

I see that, Alastair was able to provide a response, but for those of you, we definitely do. It's gonna be a separate tab and you're filtering to look at some of those billing objects alongside those CPQ objects.

Nippon, Nippoon. Can we push the CPQ data to version control together with metadata?

As I mentioned before, it's something that we are absolutely working on behind the scenes. We've seen some initial slices of that, with source control, but it is a work in progress. That should be coming here shortly.

Dan, a pretty general question here, but a good one from Dan Hines here is how much of a time saver was it to use gear set Of course, I could answer this, but I'm I may tap on Deepak and Grant's shoulders. If you guys have any sort of estimation around maybe what those time savings looked like, as we think about Grant, you positioning this a little bit of without gear set and with gear set. Any thoughts from from you Deepak and Grant on some of those time saving you you guys have seen only from you all, but maybe your clients as well.

I think you pass it to me. But yeah, I can I can answer this?

So I I kinda touched on it while I was speaking, but deployments without gear set much, much longer. And the bulk of that time was being spent in these very manual, data migration steps.

One other thing that sort of adds to the complexity there or time there is like being able to do one of these CBQ deployments requires a good bit of knowledge on the just CPQ data architecture, which is sort of just an added piece of this.

But even with like a pretty in-depth knowledge, ping on the size of the deployment. It's gonna take you several hours, I would say.

Just because import or exporting all your data than importing, getting those re new record IDs doing your translations, maybe in spreadsheets to correctly relate things to each other just takes time, especially as you start using more of the advanced features like with bundling that just increases the number of really records and object types that you have to deploy.

So it it it would be really unpredictable how much time it would take us, to deploy just because it's hard to say how long a data migration will take.

One other thing though that adds to the amount of time it takes is the smoke testing on top of that when something is incorrect because of the manual steps you've taken, you get errors, but oftentimes those errors are not clear and easy to interpret. So really what that means in order to solve those is you have to sort of walk things back and find where the issue is and then address that. So that just further adds to the time it takes for deployments.

One thing I was looking for this quote. One of our colleagues internally, was talking about a sandbox refresh, because remember, it's not just deployments. If every time you do a sandbox refresh, this data is lost. The exact quote is and this isn't this is just our company internally He said, is this real? I literally don't believe it, CPU refresh in three minutes for new sandboxes.

Right? So, again, because we're taking away all that the data, exporting and importing, it's just a click. Right? It's just a line item that you're deploying. So, Yeah. Five minutes ish for refresh.

Yeah. I I would have never been able to do a deployment of this size and the time that we had scheduled for this are today.

But, like, if I, like, we very easily could have click deploy on this gear set package, and watched a deploy in the time that we had here. Like if I look here, I can see the total deployment time when I click deploy was three minutes. It took three minutes to move all of that metadata into our production, move all of the CBQ data into production, have it related the correct way.

That even generated these nice, record IDs for us. And I was able to hop right in and start using the system.

And really nothing to address from a smoke testing standpoint. So it's significantly, significantly faster.

Are nice. Okay. Now I wanted to come over to Steve Payne. You had a question about, can we use our own ID values to get those populated into the gear set ID field, then it looks like you clarified a little bit there, Steve, on I know gear set external ID is provided by you guys, but I'm asking if we can populate it ourselves on some objects.

The answer to that question is you will be able to do that using in combination Gearsets compare and deploy tool. If you would like to, first and foremost, deploy over the metadata field that houses those external IDs following that up with a data deployment using gear sets data deployer, you'll be able to then populate those values in those now existent metadata fields. So a couple phase approach there, you could certainly do that. The wizard itself I've alluded to that a bit ago.

That is going to essentially automate that two step process, where a part of doing that the first time, gear set's going to create the field, populate the field, and then move on to allow you to start using the CPQ solution Steve, I hope that answered the question, but certainly throw some more thoughts in. If not, we had a comment from David gen gentiles again here. It's also very challenging to deploy quote templates if they're being used in all the related objects, a CPQ object that we allow for movement of those records, and some of those dependencies like Grant showed in our demo here.

Yep.

I think that brings us to the end of our, chat here.

We're right up at time here, everyone. Eleven fifty nine. Wanna start by thanking Deepak and Grant for the an amazing presentation. We hope everyone that attended got some serious value out of what you saw today.

And, again, I wanna thank everyone for the engagement in the chat, not only throughout the presentation, but also in our Q and A session Everyone have a fantastic day. And if you have any questions, Christina threw in the links to some of our LinkedIn profiles. You can email us The recording to this will be going out to each and every one of you after the call. But with that said, everyone have a fantastic day.