When you’ve got a crucial deployment to make or a narrow release window, the last thing you want to spend valuable time on is picking apart why a deployment failed or rebuilding the package on the fly. One way around this is to check ahead of time that your deployment package will successfully deploy. The deployment can then be swiftly promoted on demand, safe in the knowledge that the tests have passed and you haven’t missed any crucial dependencies. We call these validated packages, and they're a great way to reduce deployment failures and make release day that little bit less stressful.

Creating a validated package with Gearset

  • Run a comparison (see how) with an org as the target metadata location
  • Select some components to deploy (see how)
  • Click Next
  • On the pre-deployment summary, select Validate deployment
  • Gearset will begin a check-only deployment to your selected org. Nothing will be deployed to your org at this stage. If anything goes wrong - for example, the deployment fails or tests don’t pass - we’ll show you exactly what happened so you can fix it.
  • For advanced users, you can also specify the level of testing (learn more) you would like to carry out using the arrows on the Validate deployment button.
  • Once the validation completes you'll be shown the validation success screen. At this point, the package will automatically be saved into your Validation history.

Note: you can't create a validated package when deploying to a source control repository.

Deploying a validated package with Gearset

Once validation is complete, you have three deployment options:

  • Deploy the package immediately
  • Schedule the package for automatic deployment
  • Work with team members to review and deploy the package together

Deploying a validated package manually

From the validation successful page, click Deploy now to begin immediate deployment of the package.

Just like when validating, you can also specify whether to run tests when deploying by using the arrow options on the Deploy now button (learn more).

If your org supports Salesforce quick deploy, and you ran tests when validating your package, Gearset will attempt to deploy your package without re-running tests. This can make the deployment much faster than the initial validation.

Note: when a package is deployed, it is removed from your validated packages history and the entry is added to your deployment history.

Scheduling automatic deployment of a validated package

Gearset can automatically deploy your validated package at a specified date and time, and send you an email when the deployment is complete. This means you don't have to be there to press deploy if you have a scheduled maintenance window.

You can schedule automatic deployment from either the package validation success page, or from your Validation history using the Schedule button

  • Click Schedule
  • Set the date for deployment
  • Set the time for deployment (in your local time zone, set in the account page)
  • Enter email addresses to receive the deployment report (optional)
  • Click Save
  • The scheduled date will now be shown in for the package in your validated packages history
  • To change the time for a schedule deployment, click the Schedule button again. To remove the scheduling, click the red cross icon next to the scheduled time.

Working with team members on validated package

Validated packages are shared with other members of your team in Gearset, and those created by team members will appear in the results alongside your own.

If you have set up the requisite org permissions and shared access, you can collaborate on validated packages, inspect packages created by others, and even deploy them. See the the guide on teams and sharing for more information.

Viewing and managing saved validated packages

All validations will be saved in your Validation history. This page lists key information about your saved packages:

  • Owner: who created the package in Gearset
  • Friendly name: you can enter a name in here to make it easier to identify the deployment in the future (e.g. Sprint 3 March 2017). This name will be carried through to the deployment history, if entered
  • Validation status: Succeeded or Failed
  • Source username: the source metadata location
  • Target username: the target metadata location
  • Package created: when the package validation began
  • Expires in: time before the package expires (see section below for more info)
  • Scheduled: if the package has been scheduled for automatic deployment, the time and date of the deployment will be shown here
  • Actions: a range of actions you can take on a validated package


A number of actions can be performed from the Actions column. The actions depends on the validation status.

For successful validations:

  • View summary: inspect the package contents and any deployment notes
  • Schedule: set a date and time for automatic deployment of the package
  • Deploy: deploy the package immediately
  • View comparison: view the original comparison that this validation was created from (via the cog icon)
  • Download package: download the raw package XML (via the cog icon)
  • Delete: delete the validated package from your history - this can't be undone!

For failed validations:

  • View errors: view a list of deployment errors
  • View comparison: view the original comparison that this validation was created from
  • Download package: download the raw package XML (via the cog icon)
  • Delete: delete the validated package from your history - this can't be undone!

Filtering and searching validation history

You can search for items in your history using the search box above the table of results. 

By default, the validation history will display validations carried out in the last 10 days. You can change this filter view by clicking on the date range to the right of the filter box.

The results can be sorted by column by clicking on a column header - by default they are sorted by date, with the most recent at the top.

You can also filter the history by validation status. You can view all validations (default), or only successful or failed.

Package expiry

Packages are based on snapshots of your environments created at the comparison stage. This means any changes in your orgs that happen between package creation and deployment won't be accounted for, and could be overwritten when the package is deployed.

In addition, Salesforce currently enforces a 10 day window on the quick deploy feature. Deploying a package outside of the 10 day validity window will mean tests will have to be re-run on deployment.

To reduce the chance of orgs changing under your feet, and to make the most use of the quick deploy feature, Gearset validated packages expire 10 days after creation. The expires in column in the results show how long until a package expires.

We recommend you deploy any validated packages within the 10 day window. You can, however, schedule and deploy them outside of this window, but will be shown a warning before confirming the deployment.

Did this answer your question?