In this Article

• Example 1: Identifying Pending Work by Owner 
• Example 2: Analyzing Rules by Execution Status and Severity 
• Example 3: Tracking Daily Trends Across Markets 
• Example 4: Monitoring Total Number of Tables 
• Example 5: Pivot Table

Overview
 

This article demonstrates how to translate real business requirements into effective widgets. Each example explains the reasoning behind configuration choices so users understand not just what to select, but why.

For a additional details on dashboards and widgets, please refer to the article Dashboard and Widgets

Example 1: Identifying Pending Work by Owner

Business Requirement

The objective is to view the number of glossary terms that are currently pending approval and to identify the users responsible for reviewing and approving those items.

Configuration Thought Process

Asset Type

Select Glossary Term, since glossary terms go through an approval workflow.

Metric

Choose a Count metric to show the total number of pending items.

Filters

Apply a filter:

• Workflow Status = Awaiting Approval

Slicer

Add a slicer for:

• Owner (to group pending items by responsible user)

Chart Type

Select a Bar chart.
Since only one slicer is used, a non-stacked chart clearly communicates comparison across owners.

Result

The chart displays the number of pending glossary terms per owner.
Data labels make comparisons easy, and the slicer highlights how workload is distributed.

Example 2: Identifying Failed DQ Rules by Domain and Failure Type

Business Requirement

For the Data Quality rules that we have created, we expect zero exceptions.

We want to see the count of rules that were not successfully executed, grouped by Domain.

Additionally, we want to understand whether failures are due to:

• Failed
• Invalid
• Exception

This helps identify:

• Which domains are experiencing the most execution issues
• Whether problems are primarily data failures or execution/system-related issues

This requirement genuinely requires two slicers to provide meaningful insight.

Configuration Thought Process

Asset Type

Select Rule, since execution results are attributes of rules.

Metric

Choose Count, representing the number of rules that did not execute successfully.

Filters

Apply a filter for:

• Run Status IN (Failed, Invalid, Exception)

This ensures the widget focuses only on unsuccessful executions.

Slicers

First slicer:

• Domain
  This groups rules by business domain, ensuring multiple columns appear.

Second slicer:

• Run Status
  (Failed, Invalid, Exception)

This allows each domain column to be broken down by failure type.

Both slicers are essential:

• Domain shows where problems exist.
• Run Status shows why rules did not succeed.

Chart Type Selection

Select a Stacked Column Chart, because:

• Two slicers are required.
• The total height of each column represents total failed rules per domain.
• Each stacked segment represents the failure type.

A non-stacked chart would not represent both dimensions effectively.

Result

The stacked column chart shows:

• Total unsuccessful rules per domain
• Breakdown of failure types within each domain

This makes it easy to:

• Understand whether failures are mostly data-related (Failed) or system-related (Invalid/Exception)
• Prioritize remediation efforts

Example 3: Tracking AI Agent Usage Across Markets

Business Requirement

The objective is to track how usage of a specified DvSum AI Agent changes over time while comparing trends across multiple markets.

Specifically, this view should display how many questions were asked of the AI Agent over the last 60 days, with daily values shown for each market.

This allows users to:

• Compare adoption across markets
• Identify growth trends
• Detect sudden spikes or drops in usage

Configuration Thought Process

Asset Type

Select Agent Question Analytics, as it contains records of when AI Agent questions were executed.

Metric

Choose Count of Questions, representing the number of AI queries executed.

Filters

Apply filters:

• Date range = Last 60 days
• Agent = Selected AI Agent

These filters ensure the widget reflects only the relevant timeframe and agent.

Slicers

First slicer:

• Query Executed On – Daily

The business requirement explicitly calls for daily values, so the granularity must be Daily.

Second slicer:

• Market Code

This ensures each market appears as a separate data series.

Chart Type Selection

Select a Line Chart, because the goal is to analyze trends over time.

• X-axis: Date (Daily)
• Series: One continuous line per Market Code

Result

The line chart displays:

• Dates on the X-axis in chronological order
• One continuous line per market
• Clear comparison of market-level trends

This makes it easy to:

• Compare daily adoption across markets
• Detect anomalies
• Understand usage momentum over time

Example 4: Monitoring Total Number of Tables

Business Requirement

The objective is to quickly see the total number of tables in the system.

This provides a high-level view of the organization’s data landscape and helps stakeholders understand the overall scale of managed data without reviewing detailed reports.

Configuration Thought Process

Asset Type

Select Table, since table metadata is tracked at the system level.

Metric

Choose a Count metric to display the total number of tables.

Filters (Optional)

• Domain (e.g., Finance, HR)
• Data Source

These filters allow the KPI to focus on a subset of interest.

Slicers

No slicers are added.
KPI widgets are intended to display a single aggregated value.

Chart Type

Select a KPI chart, as it is designed for high-level summary metrics.

Result

The KPI widget displays:

• A single number representing total tables
• A clean and simple visualization for executive dashboards
  
   

Example 5: Pivot Table

Business Objective

Provide a consolidated view of DQ Rule execution outcomes across recent runs so users can monitor rule performance and quickly identify rules that are generating exceptions.

This enables data quality analysts to track rule behavior over time, detect recurring data quality issues, and prioritize investigation for rules that frequently fail or generate exceptions.

Example

A data quality analyst wants to:

• Monitor execution outcomes of DQ Rules across recent runs

• Identify rules generating exceptions

• Compare successful runs vs exception runs

• Detect patterns in rule execution over time

To support this analysis, the analyst creates a Pivot Table widget using rule execution history.

Widget Setup

1. Navigate to Dashboards → Add Widget

2. Enter a title for the widget

3. Select Asset Type: DQ Rules History

4. (Optional) Apply Asset Filter Criteria to limit results to a specific domain, schema, or rule category

5. Select Chart Type: Pivot Table

Pivot Table Configuration

Rows

• Rule Category

Columns

• Run Date – Daily

Metric

• Count

Sort By

Optional

Result and Interpretation

The Pivot Table displays execution counts for each DQ Rule across multiple execution dates.

Each row represents a DQ Rule, while the columns represent execution dates. The count metric indicates how many times each rule executed on a given date.

This structure helps users visually track rule activity over time and quickly identify periods where rule executions increased or where issues may have occurred.

Key Insights

From this widget, users can quickly identify patterns such as:

• Certain rule categories executing more frequently than others (for example, Foundational DQ rules showing higher execution counts).

• Dates where rule execution activity increased or decreased, which may indicate operational changes or pipeline delays.

• Periods where no executions occurred for certain categories, helping identify potential scheduling or configuration issues.

• This consolidated view enables analysts to quickly assess rule activity trends and identify areas that may require further investigation.