RCA product page demo

Share with

Description

In this video, we showcase Gearset’s Salesforce Revenue Cloud Advanced (RCA) deployment solution for Salesforce orgs. See how to manage RCA deployments and metadata efficiently across your Salesforce environments.

In this demo, you’ll learn how to:

  • Run the external ID wizard for configuration data
  • Create feature branches and manage pull requests
  • Validate changes before merging
  • Handle complex relationships with RCA metadata
  • Gain insights into sandbox updates and conflict resolution

Learn more:

Relevant videos:

Transcript

I'm going to take you through a quick tour of Gearset's Sport Revenue Cloud Advanced. Before you start to deploy Revenue Cloud Advanced, the first thing you should do is to make sure that you've run the external ID wizard on your organizations.

The external ID wizard allows Gearset to identify all of your configuration data and treat it as if it were metadata.

You can find the external ID wizard here on the org connections page.

Gearsay will automatically detect the RevenueCloud advanced objects in your org and add unique external IDs to them.

Gearsay will also add flows that make sure that when you clone records, the ID remains unique.

Once you've run your wizard, the next thing to do is to go into your pipeline.

You may want to add your RevenueCloud advanced sandboxes in a long term project.

This means that the long term project stays up to date with goings on in the main BAU pipeline, but you can work on your Revenue Cloud Advanced implementation separately and then pull it into the main pipeline when you're ready.

I'll give you a quick example of what this looks like.

First, I create a new feature branch. And if I want to, I can choose to add in a ticket from my ticketing system.

In this case, I'm just going to call this Arcelier feature one.

I'm going to use one of Gearset's RCA default filters. I can set product catalog management or pricing or maybe rate management. In this case, I'm gonna start with product catalog management because this is the one that I'm building first.

I'm going to click compare now in case it's going to run a comparison.

After comparison loads, I'm going to be able to find all of my components within the comparison.

To start with, you can see metadata as it appears in both my source and target environment.

And as the metadata is retrieved, so is the config data. I switch my view here to look at just my product catalog management components. We can see my product, product category, product attribute division stacked just so. What I can also do is open up these drop downs and see how they relate to each other. This product attribute definition has a dependency to this product classification attribute, product attribute category, attribute definition, product, and custom object as well. Gears is able to map these relationships between data and metadata fluidly to make sure that as a user, you bring in the item you want to deploy and all of its dependencies as well.

I'm going to click next, and that's going to bring me through to the step where Gearset checks my proposed deployment package.

If at this stage Gearset finds that there's any issues, it'll warn me, and I'll make sure that I need to add in these components.

Now here, notably, you can see that the metadata has changed. So Gearset's suggesting that I include the metadata, which I do want to do.

And that's going to make sure that when we make this deployment, Gearsall will deploy metadata changes first followed by data changes so that when I deploy data, the fields that that data is deployed into already exist in the target.

I'm going to click now into my predeployment summary.

You can see here summary of all of my changes, metadata, and config data, metadata to be deployed first.

I'm going to make sure that my work item records these if I have a work item included.

And then I'm going to go ahead and commit changes. This is going to add these changes into my feature branch on source control.

Now I don't actually need to go into source control at this stage because the next thing I'm going to do is I'm going to create a pull request directly from the Gearset UI.

I'm going to summarize changes using Gearset's inbuilt AI feature here.

And once the changes are summarized, which are going to let my reviewer know what to look at and let them know what's changed and what the expected impact is, what they should pay attention to, I'm going to go ahead and create that pull request.

The pull request is going to show up in my pipeline. Just let everyone know that there is now a change that I've submitted to this next environment.

What we can see on screen is the validation of this.

So we're making sure that the delta of the changes that I've introduced in that branch can validate successfully against their intended target. We want to know this validation is successful before we go ahead and attempt to merge.

We can also see here any specified Apex tests, end to end tests, and any reviewers and other checks that I might want to add as well, and any post deployment steps.

We can see the files with changes in SPR and the sum of all of the commits that I've made to this branch as well.

Now that the branch is validated, we can go ahead and merge it. And just to recap what we're looking at here, we have two changes that have come from the main pipeline back into my RCA testing sandbox. I should probably merge those first, actually. And I also have the change that I've just submitted coming into this RCA test sandbox. This is going to make sure that the test sandbox has information about what the production org looks like at the moment, which is these changes, as well as the new change that I'm submitting as well.

Going to go ahead and promote that.

Once we're ready for the whole project to come into my main pipeline, what I'll need to do is to click on it and create a pull request, and that will take the whole project and move it as one PR to QA and then eventually up to production.

Gearset support for moving RCA as metadata allows Gearset to treat complex relationships with lots of interesting, like, polymorphic relationships and requirements as easily and as efficiently as we would treat any metadata components, which also allows us to apply some really interesting logic to them. We can use sandbox updates to bring them back into sandboxes and make sure that they're all up to date. And we can also apply merge conflict logic as well to make sure that even if multiple people are submitting changes that no one's treading on each other's toes.

Please let us know any feedback you have, and we would love to hear your thoughts on RCA support from Gearset.