How to deploy reports and dashboards in Salesforce

How to deploy reports and dashboards in Salesforce

David Runciman on

Share with

LinkedIn
Twitter

Reports and dashboards are one of the most used parts of Salesforce. Across the business, managers and their teams depend on the insights gathered from Salesforce data to evaluate their progress, make strategic decisions, and report on their performance.

It’s best practice to work on reports and dashboards in a sandbox, before deploying them through your release pipeline to production. While this massively reduces the likelihood of errors impacting the wider business, it can be a slow process that delays your end users from seeing value. In this post, we’ll show you how Gearset helps you easily migrate dashboards and reports between orgs.

The difference between Salesforce reports and dashboards

Your Salesforce end users may need some help deciding on the best tools for their data exploration, and you can help by explaining the difference between reports and dashboards in Salesforce.

If they’re looking for an overview of their performance across multiple KPIs, a series of charts and graphs on a dashboard will help them to visualize the data. If they’re looking for a more in-depth and interactive way to scrutinize a particular area, a report is ideal.

There are four types of Salesforce report to choose from:

  • Tabular. Provides a simple table with rows of data, useful for straightforward analysis of a basic dataset.
  • Summary. Allows data to be organized into groups, helping teams to analyze datasets by category.
  • Matrix. Adds another dimension to the grouping, so teams can see two types of data categorization in combination.
  • Joined reports. Combines multiple reports into one so teams can analyze related datasets together.

This post focuses on regular Salesforce reports and dashboards, but you can also create custom report types that are represented with ReportType metadata. If data needs to be pulled in from other platforms, your team might consider Tableau CRM (formerly Einstein Analytics, … formerly Wave).

Gearset DevOps Summit: Developing a long-term Salesforce DevOps mindset

Find out more

Report and dashboard folders in Salesforce

Reports and dashboards are all kept in folders, and there are a few things about these folders to bear in mind during deployments.

When you deploy a report, the report folder must either already be present in the target org or deployed along with the report — and the same applies when deploying dashboards.

Reports and dashboards can be kept in the “Private Reports” and “Private Dashboards” folders. In Salesforce Classic these folders are called “My Personal Custom Reports” and “My Personal Dashboards”. There’s no way to deploy these private reports and dashboards — they need to be moved to other folders first. Access can always be controlled using permissions settings, if they need to stay private.

Users can create new folders for public reports and dashboards. But by default, public reports will be stored in the “Public Reports” folder (“Unfiled Public Reports” in Classic). As we’ll see, not every tool can deploy those reports.

Can you deploy reports and dashboards in Salesforce using change sets?

It’s possible to deploy reports and dashboards using change sets, but it’s a slow and error-prone process. Common blockers include:

  • Reports in the Public Reports folder can’t be deployed via change sets, even though they can be added to a change set.
  • Reports and dashboards need to be deployed with their dependencies, but you’ll generally only catch a missing dependency once your change set deployment has already failed with an error message like Cannot find folder:Foo.
  • Using change sets, there’s no visibility into how reports and dashboards have changed, no options for rollback, and no support for deleting reports and dashboards as part of the deployment.

How to deploy Salesforce reports and dashboards

NOTE: Gearset’s comparisons have had an upgrade! We’re in the process of updating all our blog posts with the new UI images, but in the meantime you can find out more here.

The following walkthrough will guide you through a manual deployment in Gearset, migrating some reports and dashboards from a developer org to a staging org. If you want to follow along and deploy your own reports and dashboards, you can try it out on a free trial of Gearset.

1. Select your source and target environments

First, choose the orgs you’ll deploy between. The same workflow would apply between any two environments — whether they’re orgs of any kind, Git branches, or even local files.

Screenshot of the first stage in Gearset’s metadata compare and deploy engine, where you select the source and target environments for your metadata deployment.

2. Retrieve report and dashboard metadata

After selecting the source and target environments, click on the Comparison filter drop-up and then Manage customer filters. The filter allows you to choose which metadata to retrieve from Salesforce. It’s a good idea to only select the metadata types or items you’ll deploy — retrieving more metadata via the Metadata API takes longer and only adds noise to the comparison view.

Image of Gearset’s metadata filters menu, where you can select standard metadata filters or click manage custom filters to create your own.

Gearset’s default metadata filter doesn’t include reports or dashboards, so make sure both are included. You can retrieve all reports and dashboards, or switch the All items toggle to Named items and specify the particular reports and dashboards you’re deploying.

Screenshot of Gearset’s manage custom filters window, where you should include reports and dashboards in the metadata comparison.

Unlike change sets, Gearset supports comparing and deploying reports that are in the Public Reports folder. As the Salesforce Success Community worked out, the Public Reports folder isn’t returned by the Metadata API if you request all folders in the org, but you can retrieve the reports in that folder if you explicitly request all the items in unfiled$public. Gearset handles this for you.

Once you’ve finished with the metadata filter, click OK then Compare now.

3. Identify the changes you want to deploy

On the comparison results screen, you may find it useful to filter by metadata type or search for specific reports and dashboards using the search bar in the top right.

Along the top, you’ll see that Gearset categorizes the differences into:

  • All items. Every item of metadata that was retrieved based on your metadata filter.
  • New items. Metadata that’s in the source and not yet in the target.
  • Changed items. Metadata that’s in both source and target, but doesn’t look the same.
  • Deleted items. Metadata that’s not in the source, but is in the target.
  • Selected items. Updated as you select items to deploy.

In the bottom half of the window, Gearset shows you the exact difference between source and target for each item you select.

Image of Gearset’s metadata diff viewer, where you can see the differences between your source and target orgs.

Clicking the dropdown for any item will show you both the metadata it depends on and that it’s used by. This helps you to understand your metadata model and include all the relevant dependencies in your deployment package.

Screenshot showing how Gearset highlights the dependencies of each metadata component.

Once you’ve selected items to deploy, click Next.

Screenshot of selecting the desired reports and dashboards for the deployment.

4. Check the package

Gearset runs problem analysis on every deployment package to look for issues that are likely to cause deployment failure. Missed dependencies are a classic case. So, if you select an item to deploy but not its dependencies, Gearset offers to include them for you. When you’re deploying reports and dashboards, Gearset will make sure you include related reports and folders.

Screenshot of Gearset’s problem analysis screen highlighting possible problems with the deployment and suggesting a fix.

Gearset has a handful of other problem analyzers specifically designed to help deploy reports and dashboards more successfully. You can see these on the Problem analyzer templates page in the app, where you can toggle which problem analyzers are automatically applied during CI job runs.

Beyond the problem analysis stage, Gearset will display a deployment summary. Check over the package one last time, then add a name and description to the deployment.

Screenshot of Gearset’s summary of the items included in this deployment, which allows you to check your package for a final time.

5. Deploy or schedule for later

You can now deploy your reports and dashboards! It’s a good idea to validate the deployment first, and make sure Salesforce doesn’t report any issues. You can also schedule the deployment for later.

Image of the final screen in Gearset’s metadata deployment engine reporting that the deployment was successful.

Get your Salesforce dashboard live in a dash!

Most Salesforce metadata types have a few quirks that can trip you up during deployments and cost time. Reports and dashboards aren’t super tricky, but Gearset’s deployment solution will make sure you don’t fall foul of those folders. If you haven’t already begun your free 30-day trial of Gearset, put it to the test with your own reports and folders to see how much time you save.

Try all of Gearset for free