Reporting Queries

Last updated: October 20, 2026

Overview

A Reporting Query is a saved question about your data: which data source to read, for which site, over what date range, and with which filters. You build it once on the Queries page and attach it to as many widgets as you like, so a change to the question reaches every widget that uses it instead of being repeated widget by widget.

Before queries had their own page, every widget carried a private copy of its question. Two widgets that needed the same incidents meant building the same filters twice, and the two copies drifted apart as soon as someone edited one of them. A saved query keeps one version of the question and lets you share it, control who can change it, and see exactly which widgets depend on it before you edit or delete it.

In short

Roles and Access

You need the new reporting experience turned on for your instance, and you need access to the Configuration area. Your role needs the Reporting Dashboard privilege (or Client Access), the same requirement as for Widgets. Anyone who can open the Queries tab can create queries.

What you can do with an individual query depends on the access level it gives you:

New queries start owner-only. Queries that existed before this release take their sharing from the widgets that already used them—refer to Controlling Who Can Use a Query.

The Queries List

The Queries page lists every saved query you can see, so you can find the one you need, open it, or clean up the ones you no longer use. Open it from Configuration > Reporting Dashboard > Queries.

Each row shows the query's Name, its Owner, its Created Date, and its Modified Date. Select a column heading to sort by it; select it again to reverse the order, and a third time to return to the default order, which is by name. The page shows 48 queries at a time, and the counter at the bottom—for example, 1–48 of 159 queries—tells you how many there are in total.

• Search: type in Search queries to narrow the list by name. If nothing matches, the page says No queries match and offers Clear search.

• Refresh: select the refresh icon to reload the list.

• New Query: select + New Query to create a query.

• Open a query: select its row.

• First-time view: before anyone has created a query, the page says No queries yet and points you to New Query.

Queries owned by System are built-in queries that D3 supplies. You can open them but not change or delete them, and their checkboxes are disabled.

Creating a Query

Creating a query defines the data a set of widgets will share. You choose the data source, the site, and the date range, then narrow the data with filters.

1. Go to Configuration > Reporting Dashboard > Queries.

2. Select + New Query.

3. Enter a name in Query name. Choose a name that tells other people what the data is, such as Q3 Ops - Critical Open.

4. Select a Data source: Artifact, Event, Global List, or Incident. If you choose Global List, select which list to use.

5. Select a Site.

6. Select the date range. Choose a preset such as Last 7 days, Last 30 days, Last 12 months, or Last full month, or pick exact dates on the calendar. The line under the control, such as Based on Incident Created Utc Time, tells you which date the range is measured against. Global Lists have no date range.

7. Select + Field to add a filter rule. Choose a field, an operator (in, not in, is empty, or is not empty), and one or more values. Select + Group to add a nested set of rules. Use the AND menu at the top of a group to choose how its rules combine.

8. Select Run Query to preview the results.

9. Select Save.

Other controls in the editor help you shape the data before you save:

• AI Build Query (shown when AI reporting is turned on for your instance) writes the filters for you from a plain description.

• Configure Columns chooses which columns the query returns and in what order.

• Download saves the previewed results to a file. It is available once a run returns rows.

• Simple Mode and Advanced Mode (shown only to people who can write their own aggregation scripts) switch between the filter builder and a script editor. Use Advanced Mode when the filter builder cannot express what you need: you write your own Python aggregation script, run it, and see its output. The toggle appears only when script aggregation is turned on for your instance and your role is allowed to use it.

Saving and Applying Changes

Saving works the same way in the query editor and the widget editor: one Save button, no separate Cancel, and you stay on the page afterward so everything else you can do with the record is still in front of you.

• Save keeps you on the record's own page. A new query or widget moves to its own page after the first save, which is why Permissions and Used by appear straight away instead of after you reopen it.

• Back arrow (top left) leaves the page. Anything you have not saved is discarded, which is why there is no Cancel button.

• Save and Apply replaces the old Save followed by Back to Create Widget. It appears when you open the query editor from a widget by selecting Create New Query.

To create a query while you are building a widget:

1. In the widget editor, select Create New Query.

2. Name the query, choose its data source, site, and date range, and add any filters.

3. Select Save and Apply.

Using a Query in a Widget

A widget gets its data from a query, and picking a saved query means the widget always shows the current version of it. Several widgets can use the same query.

1. Go to Configuration > Reporting Dashboard > Widgets and select + New Widget, or open an existing widget.

2. Under Widget type, select Select a chart type and choose a type.

3. Under Query, select Select a query.

4. In Use a Saved Query, search for the query by name and select its row.

Three things to know when a widget uses a saved query:

• Editing the query updates every widget that uses it. Change the filters once on the Queries page and each widget shows the new data the next time it loads.

• The date range comes from the query. The widget shows the query's date range. Turn on Override next to Date range to give just this widget a different range.

• The data source is for reference only. To use a different data source, pick a different query.

Widgets that carry their own query from before this release are unaffected and keep working as they did.

Checking Where a Query Is Used

Because editing a query changes every widget that uses it, the query editor tells you how many widgets depend on it so you can check the impact before you edit or delete it.

On an existing query, the Used by button in the header shows the live count, for example Used by 2 widgets.

1. Open the query.

2. Select Used by 2 widgets.

3. Select a widget's name to open that widget's editor.

When no widget uses the query, the button is disabled and reads Used by 0 widgets. Hover over it to see Not used by any widgets. The count and the list include every widget that uses the query, including widgets you do not have permission to open.

Controlling Who Can Use a Query

A saved query can feed widgets that many people depend on, so you decide who may read it and who may change it. Queries use the same access model as dashboards and widgets, which means sharing a query works the way you already share those.

The permission badge

Next to the query name, a badge shows the query's sharing state at a glance. Hover over it for a short explanation.

Setting permissions on a query

You need Editor access to a query to change its permissions. The Permissions button appears in the query editor's header once the query is saved.

1. Open the query and select Permissions.

2. On the Add Site(s) tab, tick the sites to give access to. Choose All Internal Sites or All Client Sites to cover a whole category, or tick individual sites. Use the Add User(s) tab to add individual people.

3. Select Add.

4. On the next step, use the access-level menu beside each site or user to set what they can do. Newly added sites start as Viewer.

5. Close the dialog.

Changes save as you make them; the dialog confirms All changes saved. The badge beside the query name updates when you close the dialog.

Access levels

Groups and roles are set under a site: select a site in the By Site tab, then use its Group and Role tabs.

How access is decided

When more than one setting applies to you, select How access is decided in the dialog to see the order. In short, private mode overrides everything and only the owner keeps access; owners always have Editor access; otherwise the most specific setting wins, in the order user, then group or role, then site; Not Set passes the decision down to the next level; and within one level, Blocked beats Editor and Viewer.

What a viewer sees

If you can see a query but cannot edit it, the page opens with View Only — You do not have permissions to edit or save this query. The editor is read-only, Save and Permissions are not offered, and the query cannot be deleted. This protects a shared query from being changed by someone who should only read it.

Existing queries and defaults

• Queries created before this release that are used by shared widgets take their sharing from those widgets. If several shared widgets used a query, it gets the combined sharing of all of them.

• Every other existing query, including one that no shared widget uses, starts out visible only to its owner, the same as dashboards and widgets.

Sharing Several Queries at Once

When you need to give the same people access to many queries, you can set permissions on all of them in one pass instead of opening each query.

1. On the Queries list, tick the checkbox beside each query. Tick the checkbox in the header row to select every query on the page.

2. Select Permissions (N), where N is the number of selected queries.

3. In Set Permissions for N Queries, choose the sites and users to add, then select Add.

4. On the second step, choose an access level for each site or user (Editor, Viewer, Blocked, or Not Set), or select Revoke Access to remove one. Select Apply to N Queries.

Deleting Queries

Delete a query when no widget needs it any more. Deleting is blocked while a widget still depends on the query, so a delete can never leave a widget without its data.

To delete one query, hover over its row and select the trash icon at the end of the row, then confirm Delete Query. To delete several, tick them and select Delete (N).

The trash icon is greyed out when you cannot delete the query, and hovering over it tells you why:

If you delete several queries at once and some are still in use, the in-use ones are skipped and a message lists them and the widgets using them. Built-in queries owned by System have no delete option.

RELATED ARTICLES

• Reporting Dashboards and Widgets