Dependency explorer grid

Where used metadata; Impact analysis; Impact assessment; Metadata dependencies

Ksawery Lisinski avatar
Written by Ksawery Lisinski
Updated over a week ago

The dependency grid is one of two modes, alongside the dependency tree, that allows you to investigate and action dependencies between metadata. The dependency grid allows you to search, filter and bulk-action dependent metadata at a much faster rate.

Article outline

Prerequisites

In order to use the dependency explorer grid you will need:

Switching to grid mode

From the dependency tree

When you have opened the dependency tree for a metadata component, simply right-click on either the root node of the tree, or any other metadata or metadata grouping, and select 'Open in grid view'.

From the metadata explorer grid view

From the metadata grid views, you can select one, or up to 50, metadata items and right-click to open the grid view. This will display every dependency for the selected items in one grid.

Available dependency attributes

The dependency grid shows the following set of information:

  • Source type: metadata type of the 'source' component that is used/ referenced in other metadata

  • Source API name: API name of the 'source' component that is used/ referenced in other metadata

  • Source label: Label of the 'source' component that is used/ referenced in other metadata

  • Write: For flows and process builders, this field captures if they write data into objects and fields.

  • Read: For flows and process builders, this field captures if they read data from objects and fields.

  • Trigger type: For record-triggered flows, process builders and apex triggers (if this is defined within trigger code), we specify if this is a BeforeSave or AfterSave relationship

  • Trigger action: For record-triggered flows, process builders and apex triggers (if this is defined within trigger code), we specify what record operation triggers the automation (Create, Update, or Delete)

  • Relationship description: For flows, process builders, reports, list views, and dashboards this field contains specific information about where and how the source component is used in the dependent component.

  • Dependent type: metadata type of the 'dependent' component that is using / referencing our source component

  • Dependent API name: API name of the 'dependent' component that is using / referencing our source component

  • Dependent label: Label of the 'dependent' component that is using / referencing our source component

Filtering the dependencies

All of the provided columns are filterable by string matching. Just type in a short text and filter the columns by any provided method to find relevant metadata.

Mass-actions

You can bulk-select or multi-select rows in the grid. Right now the limit is set to 50 rows at a time for performance reasons.

Once selected, you can perform one of 4 operations:

  • Create a single user story for all selected dependent metadata

  • Create multiple stories, one story per each dependent metadata

  • Mass create new tags for these items

  • Mass update tags for these items

Downloading a report

To download a report of the grid view, hover over the Large Report button in the top left corner, and click on "Listed metadata". This will download a CSV file of the metadata listed in your current view, including any filters.

Main use-cases

The dependency explorer grid allows you to conduct an instant impact assessment and codify work that needs to be done on impacted metadata. Some of the most common use-cases are:

  • For a field dependencies, filter the dependent reports to just show the ones where a field is used as a filter or a grouping. This gets rid of reports that will be unaffected by a change to the field.

  • For a field dependencies, filter the dependent list views to just show the ones where a field is used as a filter or a grouping. This gets rid of list views that will be unaffected by a change to the field.

  • For a field or an object, filter the dependent flows or process builders to understand where the data might be coming from.

  • For an object, filter the dependent flows, process builders and apex triggers to understand under which conditions a record-triggered automation runs.

Did this answer your question?