Gearset is different to other development tools for Salesforce. We've taken a unique approach which lets you visualize, understand, and manage your changes in a simple yet powerful way. 

As with any new tool, there will be a few things to learn on your way to mastery. In this module you'll build an understanding of how Gearset operates and step through the core workflow.

Almost every metadata deployment in Gearset follows the same core workflow:

This workflow applies to automated continuous integration (CI) jobs as well as standard deployments. Automated jobs will simply run through all of these steps for you and display the end result. 

Before you get started with the practical steps, let's take a look at each of these stages in more detail.

Gearset allows you to compare any two environments and see the configuration differences between them. This is the starting point for building your deployment: once you know what's different, you can choose which of the changes you want to deploy.

Whether that's Salesforce orgs, your version control system, or even files on your local machine, you can compare them all with Gearset.

Some common comparisons that you might run are:

Gearset supports any Salesforce org, and any git-based version control system. When you run the comparison, Gearset will show you exactly what metadata differences there are between your source and target.

Once you know what's different between your environments, you can choose which components you want to select for deployment. Deploying the changes moves them from source to target, to bring both environments in sync.

Checking the box next to the name of a metadata item will select it, and add it to your list of changes to deploy. This is broadly similar to how you'd build a change set. You can search and filter for metadata items by name or type using the filter box.

In the screenshot below, three items have been selected for deployment, as shown by the blue ticks next to their names.

As part of the pre-deployment preparation, Gearset automatically scans through your selected items and looks for any missing dependencies or other issues with your package.

This happens outside of Salesforce, and is part of the power that Gearset provides through its deep understanding of your metadata. If the app detects any issues, it will suggest changes that you should make to your deployment package to make it more likely to successfully deploy.

For example, say you want to deploy a new Apex class, CustomSiteRegisterController, and this class depends on a couple of other objects and fields. If you select that class to deploy, Gearset will scan its XML and alert you if you've not selected its dependent components. It'll then suggest that you include those dependencies in your deployment. This will make the deployment more likely to succeed.

Checking the boxes for each problem analyser will accept the suggestion, and make the proposed changes to your deployment package. If you don't want to include any of the suggestions, simply un-check the box next to it.

Now your deployment package is ready to release. Gearset will show you the summary of the components that are going to be deployed, including anything added as part of the dependency analysis. If you want to inspect the changes in more detail, you can download the package file to view the raw XML.

When you're ready to go, you can kick off the deployment and get that metadata released to your target environment. Gearset will upload the selected metadata to Salesforce (or git), request it validates and applies the changes, and let you track the status in real time.

Beyond helping you deploy changes, Gearset is also a powerful reporting and audit tool. Any deployment you make will automatically be stored in the app, with full reports, details, and email notifications. You can see deployments made by any of your team members and quickly search and filter the results.

The deployment history is also where you perform other actions such as rolling a deployment back or cloning it to another environment. More on that later in this module.

Now that you're familiar with the core workflow, it's time to dive in and try it out for yourself!

Before you can run any deployments with Gearset, you'll need to connect at least two Salesforce orgs. Adding a connection is quick and secure, and allows Gearset to retrieve and deploy metadata to that org using the Salesforce metadata API.

Gearset authenticates against orgs using the industry-standard protocol for authorization, OAuth 2.0. This means Gearset does not access or store your username and password.

Now that you've connected your two Salesforce orgs to Gearset, it's time to compare them to see what's different.

Gearset allows you to easily see differences in any two orgs' metadata before you deploy any changes between them. This ensures you know exactly what state both orgs are in and allows you to pick exactly what you want to deploy. No more forgotten components or accidental overwrites.

Gearset will now retrieve the metadata from your source and target orgs. It will then display the results of the comparison between them, highlighting any items that are different in the results grid. 

The top half of the screen lists the metadata items that have been retrieved. Clicking anywhere on the row of an item selects it. The lower half displays the line-by-line difference between the source and target for any selected metadata item.

You might think that these two orgs might be totally identical, given that they were both just created. Not so! You'll see a number of metadata items which are different between your two orgs. For example, you're likely to see several assignment rules and settings which are different - they reference the unique usernames in each org. 

This is an important lesson. No two Salesforce orgs will ever have totally identical metadata. Fortunately, Gearset has several ways to narrow down the metadata in your comparison so you can see only what you're interested in - you'll cover that in more detail in the next module.

For now, it's time to make a change in Salesforce and see how that is represented in Gearset.

This simple example demonstrates how changes you make to your org configuration are represented in Gearset. Any metadata changes can then be deployed to a target org to get them both in sync.

Time for a bit more practice. In your source org, add a new field to the Account object and refresh the comparison in Gearset to find it in your results.

Once you have saved your field, refresh the comparison in Gearset. You will now see two items appear under the New items tab.

Select each item in turn to see how the metadata for your new fields is represented in Gearset. Note that every line is green as these fields are entirely new to the source org.

So far, these changes only exist in your source org, so it's time to deploy them to your target org. Once you've selected the items you want to deploy, Gearset will build your deployment package and give you a chance to review and comment on the changes before you deploy them.

Gearset will now deploy your selected changes to your target org. You'll be able to see the live status of the deployment as it happens as well as a link to view the deployment status in Salesforce.

Once the deployment completes, log into your target org in Salesforce and you'll find your new field and value have appeared on your Account object! It's as easy as that. 

You'll also get an email confirmation from Gearset with a summary of the changes and a deployment report. 

Gearset saves a full history of every deployment you make in the Deployment history page. From here, you can view details of any previous deployment, download reports, view what was deployed, and quickly deploy the same changes to other orgs.

But what if your new changes were causing problems in the target org - perhaps you weren't supposed to delete that picklist value? With Gearset, you can easily roll deployments back from a snapshot of the target taken during the original comparison. This allows you to quickly restore it to its previous state.

Gearset will now roll back just that SLA field change in your target org. The other changes you deployed - the new field and associated FLS - will remain intact.

Once the deployment has completed, log into your target org and you'll find the Platinum value is has reappeared. The rollback deployment will also appear in your deployment history in Gearset, and you'll receive another email confirming the deployment.

Congratulations! You've now completed this module. You've covered the core Gearset workflow, how to add org connections, compare them, make and deploy changes, and selectively roll a deployment back.

The next module introduces metadata filters and how to use them to control what metadata you see in your comparison results.