Managing your Salesforce data with Gearset

Share with

Description

Gearset Technical Lead, Tom Smith, walks through how to manage your Salesforce data. From understanding the problems of Salesforce data through to deployment solutions for tricky data types such as CPQ and Vlocity, this session introduces you to mastering data deployments. You’ll also see how Gearset’s various data deployment solutions can help you streamline and accelerate your own Salesforce data deployment processes.

Learn more:

Transcript

Okay.

So hi, everyone. My name is Tom, and I'm gonna be talking today about managing your Salesforce data with Gearset.

Just a bit of background about myself. As I say, my name is Tom. I'm a technical lead at Gearset. I've been working in software for about nine years, the past four of which have been at Gearset. And throughout my time at Gearset, I've worked on across the product, from sandbox seeding to CPQ deployments, velocity deployments, and all of our metadata deployments.

So today, I'm gonna talk about starting off with just what is Salesforce data. I'm just gonna take a look at some definitions that we're going to use later on and make a bit of distinction around what we're talking about.

We're We're then going to have a look at what makes managing this data difficult, some of the problems you'll come across, and I'm sure you might be familiar with many of these problems already.

Then we'll take a look at how Keyaset can help with those problems, helping you to manage your data.

We're then gonna dive into some demos. We're gonna start off with a sneak peek of our CPQ deployment, which is currently in a closed pilot, and then we're gonna look at deploying some Salesforce industry changes. Salesforce industries and Velocity, same thing. I might use them interchangeably.

So let's get started with what Salesforce data is.

Now you can see here we've got a contact, and a contact is what we call transactional data.

Other things that are transactional data include things like accounts, opportunities, orders, cases. And, basically, transactional data is anything that comes as a result of a user interacting with your org.

So if I place an order, that creates a new order in our system, and it's transactional data.

Now transactional data doesn't change the behavior of our org. If I've got a thousand orders or five thousand orders or ten thousand orders, the org is still gonna work in the same way. The data grows as we have more interaction with the org, but the behavior stays the same.

Now typical things you might do with transactional data are things like sandbox seeding, where you pull your data from production into an earlier environment, which is your dev or your IT environment so that you can test your changes against it. As part of that, you might do some data masking to hide any sensitive or personal information from that data, or you might back up this data so that in the event of a data loss, you're able to go and restore that data from the backup.

Now we've also got what we call configuration data. And the example here is a product, and this is from Salesforce CPQ.

Now this laptop is something I can sell, and that means it's the behavior of my org. If I were to remove this laptop data from my org, our sales team wouldn't be able to sell it anymore. So whenever I create a new piece of config data, that's configuring how our org behaves in exactly the same way as how metadata controls how our org behaves.

So unlike transaction data, all of this configuration data comes from developers and admins.

And what you'll find is a lot of managed packages such as CPQ, Velocity, Encino, or FinancialForce use configuration data to control the behavior.

Now whereas before we found that transactional data would go from production back to a sandbox or developer org, configuration data tends to go the other way. Developer might make a change in a dev org and then push that through a DevOps process to move that change out to production.

So a quick recap of those. Transactional data is things like accounts, contacts, and opportunities, whereas configuration data is things like products, price rules, and omniscripts.

With transactional data, the records come from users interacting with the org, but they don't change the org's behavior.

Configuration data comes from developers and admins making changes to the behavior of the org, and that means that when we deploy them into production, it changes how the org works.

With transactional data, typically, we move it from prod into dev so that we can test our changes against it. Whereas config data, we're going from dev into production as part of a user story or any other work that we're trying to do and deploy into production.

So we're gonna focus on configuration data today and how we manage that. But to start off with, I wanna look at some of the problems with managing configuration data.

So first of all, when we make a metadata change, we can deploy it with things like change checks or we can deploy it with ant.

Config data isn't metadata, it's actually data and records in your org, which means you can't deploy it in the same way as metadata. You have to jump to another tool to be able to deploy this config data. You might be using Salesforce Data Loader or Workbench for example.

Now what that means is when you're trying to do a deployment, you're spending a lot of time jumping between tools, having to context switch, and you you lose focus on doing the actual deployment. You want to focus on getting your deployment done, but you're having to think, I'm now deploying metadata. I'm now deploying config data.

And it's easy to lose track of what's going on.

If somebody new were to join your team, that's then multiple tools that you have to learn and become really familiar with.

So it's hard to kind of get everything in one place.

Now I've got a picture here of the schema for CPQ.

Don't worry about trying to read this or understand what's going on here. All I'm trying to say is CPQ is is a managed package. It's got a very complex and very large schema. There's a lot of objects and a lot of relationships between all of those objects, which makes sense because CPQ has been built up over many years.

Now when I come to do my deployment, I may know I want to deploy one record, which is the record I've just changed. But I've also got to work out what else I actually want to deploy.

If I miss something from that deployment, it might mean the deployment fails, or maybe the deployment will succeed, but I won't get the behavior change I was expecting because something's missing.

What that means is all of those failed deployments, the things I have to go back and fix, I have to find my way through multiple deployments until I've got something working. So it's a lot of time spent just trying to deploy a single change by trying to figure out exactly what it is that needs deploying.

Now another difficulty comes with matching records between your orgs when you're doing a deployment.

With metadata, every piece of metadata has an API name and that lets us match a piece of metadata in my source org, one of my target org.

So if, for example, I've created a new custom field in one org, when we deploy that, Salesforce will look at the API name for that custom field.

It will see that it doesn't exist in the org we're deploying to, So it will realize this is a new custom field we need to create.

If I then make a change to the custom field and I try and deploy that, again, Salesforce will look at the API name. It will now match it in the target org, and and it will know to update that piece of metadata rather than creating a new one.

Now data doesn't have this API name. It's harder to match the data between different orgs.

We could use the Salesforce ID. All records do have an ID, and that can work to some extent. If I refresh a sandbox, my records in my sandbox and production org will have the same IDs.

But when I create a new record in production or I create a new record in the sandbox, at that point, the IDs are different. So actually those records don't line up anymore.

What we have to use is something called an external ID, which is a field where we create it to behave similar to an API name so that we can match records in one org to records in another and update, create, and delete records as appropriate.

And finally, we don't get a lot of visibility into who's making changes to the data. We don't have an audit trail for our config data.

And when I deploy metadata, I can see all of those deployments in Salesforce. I can dig into the details to see exactly who made a change or when they made it and what they changed.

If I'm using something like Salesforce data loader to deploy my config data changes, we don't get that because the deployment was from somebody's personal machine from some CSV files. We don't know what's happened there. We'll have the last modified date on all of the records, but there's no easy way to see that. We'd have to go and check all of the records individually.

Even then, we only see the most recent change.

If I'm using the bulk API, we can see the bulk data load jobs, but, But, again, we don't get quite as much visibility as metadata, and it just makes it really hard to have that audit trail for any of the compliance that we're trying to meet.

So Gearset can help with all of these problems.

Gearset can treat config data in exactly the same way as metadata, and it will fit right into your existing DevOps process.

You don't need to jump between different tools. Gearset gives a simple and intuitive UI for deploying your config data changes. If you're at all familiar with Gearsight already, it's exactly the same API sorry, the same UI as deploying metadata.

Really straightforward to deploy with both of them.

To help with that complex schema, Eos has a dependency tree, which we'll see in a few moments, to help you understand how all of your config data relates to the rest of that data and how it relates to metadata.

This lets you explore your data and find exactly what you need to include in the deployment. There's no more guessing, no more missing things. It's easy to see exactly what's there.

Now mapping the data between the orgs is something that GearSet will take care of for you. So Gearset will know if you've got a new record, if it's something you're changing, or if it's something you've deleted, and it will make sure it will update the correct record in the target for you.

And finally, Gearset gives a deployment history view, which shows exactly who's made some changes, when they made those changes, what the config data looked like before, what it looks like now. And it's easy to enroll those changes back if you need to for any reason. So you've got your audit trail there right alongside your metadata.

So I'm gonna talk now about Salesforce CPQ.

Gearset does support Salesforce CPQ deployments. We're currently in a closed pilot for this, so a bit of a sneak peek of what's coming later this year.

CPQ stands for a configured price quote.

And what CPQ does is lets you put all of your configuration and pricing logic for your sales right into your org.

If, for example, I'm buying a laptop, I might have the option of choosing what processor I want, how much memory I want, what hard drive I want. Maybe I can buy some software alongside it, or I can take up a particular warranty.

Previously, your sales team would be checking a big spreadsheet to find out what configurations they can sell this laptop in, what's valid, what processes can go with this laptop, what can go with another one.

All of that's just built into Salesforce now. When they start generating a quote, you'll be able to choose the products, and you can decide exactly what you need in that quote.

Once you've chosen every all of the products you want, CPQ will generate a price for you based on all of your pricing logic, taking into account any discounts. So you'll get this quote, and all of the behavior in the org defines how that quote can be made.

Just to clarify here, we're talking about Salesforce CPQ, formerly of course Steel Brick. There are a few other CPQ implementations out there. This is specific to the Salesforce CPQ one, which Salesforce acquired seven or eight years ago.

So I'm gonna jump into a demo in Gearset now showing how we can deploy CPQ changes through Gearset.

So I'm gonna select my CPQ org, which I've already added to Gearset.

If you've used Gearset before, you're probably very familiar with this page. If you're not, the way Gearset works is we can select one org over here and a target org over here. From there, we can compare the orgs and deploy metadata and CPQ from our source org into our target org.

So Geosets detected that I've got CVQ installed in this org, and it's prompting me now to run an external ID setup wizard. So let's run this.

Now what this is going to do is create this mapping between our different orgs to make sure that we can update records when we need. If I've got a changed record in if I've got a record in one org and a record in my target org, GESM will be able to match those up, so it updates the records when I make a change.

If the record's in the source org, we're not in the target, Gearset will recognize that's a new record and needs deploying.

Or if the record isn't in the source but isn't in the target, Gearset will say that's a deleted record.

So we'll go ahead and start creating this external ID.

What's going to happen is Gearset's going to create a custom field on all of our CPQ objects and all of our related custom objects and populate that external ID with a unique value so that we can go and match records between our different orgs.

Those IDs are all derived from our Salesforce ID, which means we're gonna have a unique value for every single record within our org.

We need to run this on all of our orgs.

And finally, when I deploy a new record from one org to another, Gearset will handle populating that external ID for me so that any future changes to that record will be updated correctly.

So if I start this setup I can see all of the objects here where we're going to create our external ID.

We give it a friendly name so we can refer back to it easily later, and let's kick that off to go and create those external IDs.

Now what Gearsaw will do at this point is, first of all, it's gonna deploy a new custom field to all of these objects, and that custom field is the external ID field we're going to use. So all of these objects will have this external ID field on them.

It will then go through and populate that external field ID field for all of the records in our org, giving it a value so that we can start to match up against other orgs.

So while that's running, I'm gonna jump into this org, and I'm gonna make a change so that we can then see how we deploy that new change.

So what I'm gonna do today is create a product rule with a few error conditions on it.

So we'll go for a new product rule here.

We'll call it we'll check quantity and price, and we're gonna run this when we select some products and save them.

Once this is saved, we're just gonna create a few error error conditions on it.

And I'm just gonna edit this quickly to make it active.

So let's create an error condition.

To start off with, we're going to test our product option.

We'll have a look at the unit price, and we're going to say that the unit price has to be greater than zero to make sure it's got a value.

We're now gonna go ahead and create another error condition.

Again, we'll go and put option.

And this time, we're gonna check the quantity, and we'll check that it's less than a hundred. We're not expecting to be selling anything in that kind of volume. So if it's over a hundred, we might want it to be an error.

So we've got our product rule here with two error conditions, and now we want to deploy that to another org. So if I jump back to gearset, we'll see it's still running through here. So we're creating that external ID on all of these objects before moving on to populate those values.

This can take a little bit of time, but we only need to run it once per org.

So we're going to deploy to another org soon where I've already run this external ID setup, which means we don't need to run it again here so we'll be able to match all of those up.

Now creating this external ID is all a metadata deployment.

If I decide later I don't want this external ID for any reason I can just go ahead and remove the external ID field from these objects. And Giaset makes it really easy for you to do that too if you need to. We can just roll back this deployment which creates the fields and it will just be dropped for us.

So we've just moved on a step now to create those external IDs. I can see there's a couple of messages in the chat. I'm just gonna check that for any questions.

Cool. Nothing at the moment.

I'll just finish off and wait for this to run through. It shouldn't be too much longer now.

It should say as well, we've made a product rule here. GESP is not limited to just the product rules. We'll be able to compare all of the objects you see here. We'll be able to look at our products, product options. We can have a look at our price book entries and everything and see how all of this data fits together.

If you've got any related custom objects, if you create an object that's, has a relationship to CPQ and you might want to deploy that alongside, Here, it will also create that external ID on that custom object for you as well so you can include that in your deployments.

So we've created the field now, and we're just running through to populate all of those values.

Again, this is all gonna be derived from the Salesforce ID for these records, so it's going to be unique for every single record within our org. And let's just jump through all of them now.

Here we go. We can see as it goes through each object.

Once this is done, I'm gonna go and have a look at the deployment history where we can see, just like a deployment, we even get the audit trail for creating this external ID and populating the values. We can see who's run it on the org and exactly when they ran it. So nothing's happening here without being tracked for us.

Shouldn't be too much longer. There's not too many records in the org.

And as I say, this is a one time setup we have to run on the org. From then on, whenever we deploy new records, any new record from the get new external ID, any change records already have one, so don't need updating. So it doesn't take us long to actually create the rec to create external ID for any changes we deploy.

Okay. So we're almost at the end now.

Just finishing off these last few objects.

Okay. So I think that's done now.

So if we have a look at our deployment here, we can even see exactly what's happening here set. We've deployed our new custom fields as well as the permissions for those custom fields on all of these objects.

And we can see that we populated the external ID for all of these objects.

If I jump up to my deployment history, we have a record here showing that I've run the CPQ external ID setup against this org at this time. And if I want to roll that back, I can, and that will just remove the field for me.

So let's have a look at comparing and deploying that product rule now. We've got our product rule with our two error conditions.

So I'm gonna jump over to compare and deploy.

We've just run the external ID setup against this org, and I'm gonna pick another one where I've run an external ID setup earlier.

We can customize a filter here to say that we want to include CPQ and kick off this comparison.

So what this comparison will do is log in to my source org. It will go and find all of the CPQ objects I've got installed in this org.

It will grab all of the records from those and download them to get a set.

At the same time, it's gonna fetch all of those records from my target org, pull all of those records down for the different objects, different objects, and then using that external ID field that we've just created, GearSet is going to match up the different records so that we can see exactly which records are new, which have been changed, which have been deleted, and we can then go ahead and deploy them.

Again, if you've used Gearset for metadata deployments, you'll see this is exactly the same process, exactly the same screen. We select our orgs, start a comparison.

If I want to deploy metadata alongside CPQ, if, for example, I'm adding a value to a pick list and I need to create a pick list value, I can even include that in the same comparison here.

So here's our comparison, and we can see all of our CPQ records within Gearset.

Now I talked earlier about this hierarchy for viewing dependencies.

If we jump back to this laptop that we were talking about, I can expand it out and see all of the CPQ configuration that links to this laptop.

I can see I've got some product options for it. We've got the processor, the hard drive, and the memory.

So it's really easy to see how this product relates to everything else in the org and to find everything else I might need to include in my deployment.

We can go even further and extend our product option, where I'll see it depends on the two products as well as the product feature. So I get this whole hierarchy of exactly how my data fits together.

As well as the product options, we've got the product features and the price per entry in here. So everything to do with this product, I can navigate through the tree. I don't need to understand everything about the schema here, so it helps me by showing me what's important.

So I'm going to try and find my product rule now.

And here we go we've got our new product rule.

Now if I expand this out we're also going to see those error conditions that I've just created. We've got the two here checking that the price is greater than zero and the other one that checks the quantity is less than one hundred.

So to deploy this product rule I'm going to need to deploy the product rule plus the error conditions.

What I'm actually gonna do here, though, is select the error conditions, but I'm missing the product rule. So I'm gonna hit next to run through and review my deployment.

Now at this stage, Gear Set's gonna have a look at the deployment for me, and it's gonna detect that I've included the error rules error conditions, but I haven't included the product rule. And that means the deployment will fail because there's nothing to attach the error conditions to.

Here, so it's gonna prompt me to include that product rule, which is gonna make my deployment more likely to succeed, and I'm not gonna have to spend time going back and figuring out what I've done wrong.

So I'll include that, and I can see my error conditions here and my product rule are the things I'm gonna deploy.

So I'm gonna give this a friendly name, which we'll be able to see in the deployment history. So it's just a handy way to refer back to it. If I'm using Jira, I can attach this to one of my stories, similar for Azure DevOps or Asana, which makes it easy to see exactly why we're doing a deployment and what piece of work it relates back to.

So let's hit deploy.

So as I said, if we're deploying any metadata, we could do that alongside this, and the metadata would be deployed. Then the CPQ data, So I could be adding a new pick list value and then deploying some records that are using that pick list value.

At this point, Gears is going to see that we've got the new product rule and new error condition.

It's gonna check the target and find that they don't exist using that external ID.

And then it's going to realize we need to create a new product rule, error conditions, and it will deploy them into my target org for me.

And once this is finished up, we can go and have a look at that new product rule in the target org.

You may have noticed earlier on when I did the comparison, I had a lot of new products and a lot of new records, a lot of deleted ones.

The reason for that is I've actually got two trial CPQ orgs here.

So although the records look the same, they're not the same. Those external IDs don't quite line up. What we suggest doing is starting by running the external ID setup in one of your higher environments, maybe in UAT.

Once we come out of closed pilot, we do even suggest prod, but for now, we'll properly keep it to UAT.

Then you can deploy those records back from that org into your development orgs. That will make sure that all of the external ID fields match, and it's easy for you to go and update those records where you'll see them all as changed or the same rather than new and deleted.

So we're back at this deployment successful page, and I can see we've created our error conditions and our product rule. So I'm gonna jump into this target org now where we can see we've got our product rule here alongside our two error conditions.

I'll just show how we can make a change and update this record. I'm gonna change the conditions met field here and save that.

And then I'm gonna go and run the comparison again.

So this is gonna do exactly the same. We've just changed the target so that we'll see that the originally, the source was needing all conditions to be met. Now the target just want any. So we'll see that difference there.

While this is running the comparison, I'm just gonna jump to the deployment history page.

And we can see here we've got the deployment that I've just done. We've deployed from this org to another one. We can see what time we've done it. And if I open up the comparison, I can see exactly what my config data looked like both before and after the deployment.

I can see my error conditions were new. There was nothing on the target before, and and I can see all of the content in here. And this can go all the way back from all of the deployments we've done. So I get to trace exactly what's been changed and who made those changes for any deployment. So we get a really good audit trail there. And this sits right alongside any metadata deployments too. All of my metadata deployments would appear in here, making it easy to see exactly who's deployed what and when.

Now if I jump back to this comparison, we'll see we've got the product rule here, and we can see that the conditions met field has been changed. And I could go ahead and deploy that, and it would update the correct record in my old for me because of that external ID.

So I'm gonna jump back over to here now.

As I say, CPQ is still in a closed pilot. We've had a few people using it for a couple of months now. That seems to be working really well, helping them get more insight into exactly what they're deploying and making those deployments more successful by finding any missing dependencies for them.

It's a closed pilot, so please get in touch if you're interested. We're hoping to move to an open pilot later this year.

Now before I move on, does anyone have any questions about CPQ? And I'll just check the chat.

Okay.

So I'm gonna talk about Salesforce Industries now.

Salesforce Industries was formerly known as Velocity. So I'm just gonna refer to it as Velocity. That's because it's shorter.

Now Velocity has two parts to it. First of all, there's industry specific data models, and these are pieces of transactional data. And what I mean by this is if you're running an insurance company, you probably got quite a bit in common with other insurance companies.

You'll both likely need a claim object or a policy object or a premium object.

Velocity provides these data models for you, which you can then customize to your needs rather than having to start everything from scratch.

And Velocity gives you these data models across different industries. There's an insurance one, a health care one, a manufacturing one, and several more.

All of that is transactional data.

If a user takes out a new policy in my org or there's a new claim, it creates new data in my org, but it doesn't change the behavior of the org, which is why it's transactional.

Velocity also has something called OmniStudio, which is our configuration data.

OmniStudio helps you to build guided user experiences through clicks, not code.

What I mean by this is it helps you build a wizard type thing to walk through different things you need to do in your org. So if I'm the user who's trying to sign up for an insurance policy, it might start by asking me to fill in my personal details, and then I click next. The next page will take the details of what I want to insure.

And depending on what that is, the wizard might take me to different different workflows. If it's a property I'm insuring, it I might get to a page where I need to fill out details of exactly how the property is built. Maybe in other cases, I don't if I'm insuring a vehicle.

So Omnisphere helps build those wizards and UIs without needing code.

And, again, Velocity was acquired by Salesforce a few years ago and was since since been rebranded to Salesforce Industries.

So we're gonna take a look at OmniStudio and how we can deploy that OmniStudio config data.

So I'm going to jump back over to Get Asset.

So just to start off with, I'm going to log into my velocity org.

Now this time, we're gonna make a change to some metadata and to some Velocity, config data.

I'm gonna start off by adding a field to my account.

We're just gonna go with a simple checkbox field for now.

We'll call it as priority account and leave the default unchecked.

And we'll set the permissions and add it to our layouts.

Now at this point, I'm gonna open up Omni Studio. And Omni Studio is where I create those guided experiences we were talking about earlier.

Now I'm gonna start with something called a data rafter. Don't worry if you're not familiar with Velocity. I'll try and talk through what all of these are.

A data rafter lets us export or import data from a Salesforce object in different formats. So I'm going to call this account extract.

What this is going to do is extract data from our account and let us convert it to a JSON format.

I can choose my account here, which is where I want to extract the data.

What I'm gonna do is filter it by ID so that I can say exactly what account I'm extracting data for. And here, I can choose which fields I want to be extracted.

So I'm gonna take the name, the account number, and this priority account field that we've just created.

Now if I preview this, I can add some parameters.

I'll just grab my account ID and paste this in.

So when I run this, what this data app is doing is it's looking for the account with this ID, which is Acme.

It's pulling that data out and converting it to this JSON format for me, which I can then use elsewhere.

Now I'm gonna jump over to flex cards now.

A flex card is essentially a piece of UI that lets us expose some data using a data wrapped as a source as well as a few other sources.

So we'll call this one account view.

We've got to configure a few pieces, and then we'll see how we can create this UI through the clicks rather than code interface.

I've got a few sources for this data, but I'm going to choose a data raptor which we just created.

We're going to take this account extract, and we just set up here a few parameters that let us export that let us specify which account we want data for.

So, again, if I put my account ID in here and click fetch, we can see the data here is exactly what we extracted from that data raptor.

Now I'm just gonna convert this into a table format, which I'll run again, and we have this table of our account data just here.

So this is our interface for creating a flex card. I've got all of these objects along the right hand side that I can use to build up my flex card.

I'm gonna start off with a text field, and we'll just put name in here, and we'll store the account name along here.

I'm gonna add a field for each of those things we want to display.

And then we'll start to pull through the data.

So what we'll see here as part of Omni Studio is I can look in this fields drop down, and it will show me all of the fields we're pulling in from that data rafter.

So I can go ahead and copy these.

And I'm just dragging this around to create this. I don't need to write any code here.

We're adding our last priority account.

If I fetch my data here, again, we can see the data in this table. So if I jump to my preview mode, what we'll see here is the UI, and it will have all of that data populated for me.

So we've got the name, account number, and the priority account.

What I also want to do here is add an action that's going to let us edit the account.

Now, Omni Studio also has an object called an OmniScript.

An OmniScript lets us have walked through that wizard. So if I pick one here, when I click this button, it's gonna let me walk through an edit account view where I'll be able to give the new value that I want for different fields on the account.

So I'm gonna activate this now. Now when we create a flex card, we're essentially creating a blueprint for a lightning web component.

So we work in the flex card, and we click activate.

That then generates a lightning web component for us, which is what we'll use across our org in any views that people are actually using for the org.

So I'll jump back over to gear set now, and we can look at deploying this to another org.

I'm gonna start off by selecting my orgs again.

And now I'm gonna open up the metadata filter so I can choose what I want to include in this comparison.

I'm gonna turn CPQ off because there's no CPQ in these orgs.

Now I'm gonna include my custom fields, and I'm also gonna include that lightning web component that's just been created when we activated our flex color.

I can jump over and choose exactly what velocity changes I want to include. So I'm going to take my data raptor because we've got a new one of those.

I'm going to include OmniScript. That's the OmniScript we had with the action button to edit account. But I'm actually gonna filter this down to just the OmniScript I want.

Filtering it down makes the comparison faster because we only pull in exactly what we need rather than pulling in all of the OmniScripts.

I'm gonna do the same with the flex card and only pull in the one that we need.

So I'm gonna click off the comparison now. Now again, looks exactly the same as the comparison when we were doing CPQ.

This time, we're logging into the org. We're downloading the metadata, the fields in the lightning web component, and we're also downloading those velocity changes, the data raptors, the flex card, and the Omni script. Both of these are happening at the same time, and it's all gonna appear together in one view. I don't need to use one tool or one part of gear set for my metadata, another part for velocity. Everything's exactly the same process.

So it's just fetching the metadata now.

You might be thinking we haven't run the external ID set up for Velocity.

Velocity actually already has something similar to an API name or external IDs built in, which means Gearset doesn't need to create one specifically for you. We're able to match up the velocity changes we've made in one org to the changes in the other org. It's based on the names, similar to metadata.

With velocity, the names are unique within a type.

So I can only have one data wrapped to call the CALDEXTRACT, meaning we can match them up automatically.

So we're just retrieving the last bit of those velocity metadata and comparing them to see what's new, what's changed, or what's deleted.

So, again, same grid, and I can see my new field here, my new data wrapped up, my flex card, and my lightning web components.

So, again, Gear Set helps us understand exactly how all of this data fits together and what I need to deploy.

If I include my flex card and expand it out, I can see it's used by the lightning web component that it created so that we know this flex card is a blueprint for this LWC. So we'll include that.

I'm gonna see what the Flexard depends on, and we've got the data wrapped in OmniScript.

Now the OmniScript, we've got a small change to, but it's already there. We don't need to actually deploy this for our org for the OmniScript to work. So I'm gonna ignore this.

But we can see as well that the OmniScript is a blueprint for another lightning web component.

I think this is just whitespace changes in here, so we won't worry about deploying this either.

If I jump back up to my data raptor, not only do I see different velocity dependencies, but I can see the dependencies between my velocity changes and my metadata. So I can see that this data raptor depends on these three custom fields.

We've got the two standard fields, so don't need to do anything with them, but we'll include our custom field.

So I've got selected here our custom field, our flex card, and our lightning web component. I'm not going to select the data raptor though.

What we'll see again is Gearset's going to look at this deployment for us, and it's gonna say you're missing the data raptor, which means this deployment isn't going to work.

To save us going ahead with the deployment and finding it fails, we can include that data raptor and get it right first time.

So now we can review again what we're going to deploy. I've got my custom field, my LWC, and on the velocity side, I've got my flex card and data raptor.

I can do the same, give it a friendly name, link it to any Jira tickets or, work items, and go ahead with that deployment.

So Gears is gonna run through now. It's gonna start off with deploying the metadata.

So it will deploy that custom field and the LWC.

Once that's done, you can move on to deploying the velocity changes, the data raptor, and the flex card for me.

And all of this will appear as one row in our deployment history. So we've done a single deployment for all of our changes.

We have that deployment in the audit trail, and we can see exactly what's happened.

So I can see here, here's my metadata, and here's my velocity changes.

If I jump up to the deployment history, what we'll see is, again, that single row. So, again, I know I'm really talking about this a lot. We've got this audit trail here. Every single deployment, whether it's metadata, velocity, or CPQ, all appears in one view.

I've seen a question pop up there, so let me take a look at that.

Jack's asking, are there any plans to support other CPQ vendors or other systems that rely on configuration data?

So at the moment, we've got the Velocity support in GearSat.

That's fully that's in GA in GearSat. You can use that on the free trial or the pro license. We've got Salesforce CPQ, which is in the closed pilot at the moment.

I would say we CPQ is the current focus. In the future, it's possible we'll expand out to other systems relying on configuration data based on demand. We have no concrete plans at the moment, though, to support any of the ones, any of the packages.

Okay.

What I'm gonna show as well is in our deployment history. Again, I can jump back to that comparison and see what's actually changed.

I'm also able to roll this back if I'm not happy with it. If we found the deployment hasn't worked as expected, we can go and compare it. And now Gearset's going to compare a snapshot of the org just before we did that last deployment against what the org currently looks like. We can take that snapshot, and we can just deploy that older version of the org right over the current one and doing all of those changes that we've just done. So it's really easy to revert and roll back anything we're not happy with.

So as as well as org to org, Velocity works with all of the kind of automation that gears it has around the metadata.

If I deploy my metadata changes into Git and then go through a pull request review process before deploying out maybe to my QA org, then to my UAT org, and finally production.

Velocity can sit right alongside that. I can commit my Velocity changes into the same Git repo as my metadata.

I can make them part of the same pull request. They can go through a review process, and then we can even set up a CI job to automatically deploy from the Git repo out to an org once a pull request has been merged. So velocity, fully supported in that whole DevOps process right alongside your metadata.

We're just taking a minute to pull this down. The snapshot we already have, just fetching the latest from, the org.

If you are familiar with Gearset, velocity will be supported in all the same ways as metadata through those CI jobs, through all of that automation, through the monitoring jobs to detect what's missing.

So we've got here previously, we had we sorry.

We've created the new custom field. So So if we wanted to roll this back, we'd be deleting the custom field now.

So that's everything for our velocity support.

So we've seen deploying from an org to another org. We can deploy metadata and velocity changes side by side.

We get the audit trail to show exactly what we've changed. We can jump in and have a look at that all the way back and see all of the changes that have been made as well as rolling back anything that we're not happy with.

So I just wanted to share a quote from one of, one of our users who's been using Velocity for quite some time now, I think a good six months at least. They were previously using Velocity DX and found that Gear Sets just helped them get all of those deployments right.

So just to recap those four problems, we're talking first about having multiple tools, having something for deploying metadata, something for CPQ, something for velocity, which meant you had a lot of context switching and a lot of, a lot of learning if you're trying to onboard someone new. Gear set puts everything in the same tool in exactly the same workflow. It's easy to deploy metadata, CPU, velocity, all in exactly the same way.

Those complex object models are hard to understand, and it makes it easy to miss something, which causes your deployment to fail, meaning you have to go back and try again.

The dependency tree in Gear Set shows you these relationships, helping you to find exactly what you need to deploy. And if we spot something that we think is missing, we can suggest that to you so that your deployment is more likely to succeed.

Gearset handles mapping the data between different orgs so that it can update records when it needs to, create records when it needs to, and you don't end up with any duplicates.

And finally, we have the audit history in Gearset showing your metadata, CBQ, and velocity deployments all side by side, making it easy to see exactly who's made changes, what they've changed, and making it easy to roll those back.

So just to recap, CPQ, Salesforce CPQ, is currently in a closed pilot.

We're still working on it, but do get in touch if you're interested. We may be able to invite you onto the pilot over the next few months. Velocity is available on our thirty day free trial, but you can sign up at gearset dot com. If you've already got a gearset license, it will be available on all of our licensing tiers, so you can go ahead and give it a go.