DEV Community

Cover image for Getting Started With Seal Reports: Sharing Filters Across Multiple Models
Vlad Ganușceac
Vlad Ganușceac

Posted on

Getting Started With Seal Reports: Sharing Filters Across Multiple Models

#sealreport #analytics #tutorial #businessintelligence

This is the seventh post in the series.

The final report may contain multiple UI elements: data tables, KPI widgets, and various types of charts. When several visual components and filters are applied, we typically assume that these filters operate globally across all underlying models.

In this post, I will use the HumanResources.vEmployee view from the AdventureWorks2025 database to demonstrate how filters can be shared across different UI components through a common model.

Defining Models

This example is intentionally simplified. All four models use only the HumanResources.vEmployee view. The naming of these models is deliberately explicit (“screaming”) to clearly reflect their purpose:

. Models
|__ 0.Shareable
|__ 1.DataTable
|__ 2.EmployeeJobTitlesChart
|__ 3.EmployeeProvincesChart
Enter fullscreen mode Exit fullscreen mode

The common restrictions are defined within the 0.Shareable model, in the section with the same name:

[JobTitle Contains ?]
AND [FirstName Contains ?]
AND [MiddleName Contains ?]
AND [LastName Contains ?]
AND [EmailAddress Contains ?]
AND [PhoneNumber Contains ?]
AND [PhoneNumberType Contains ?]
AND [PostalCode Contains ?]
AND [City Contains ?]
AND [StateProvinceName Contains ?]
AND [CountryRegionName Contains ?]
Enter fullscreen mode Exit fullscreen mode

For the remaining models, the 0.Shareable model must be referenced in the Reference model option within the Model definition section. This allows all UI components to reuse the same filtering logic consistently across the report.

Referencing the shareable model

For the 1.DataTable model, the following properties are placed within the Row Elements section:

JobTitle
FirstName
MiddleName
LastName
EmailAddress
PhoneNumber
PhoneNumberType
PostalCode
City
StateProvinceName
CountryRegionName
Enter fullscreen mode Exit fullscreen mode

For the 2.EmployeeJobTitlesChart model, the JobTitle property is placed in the Row Elements section as the axis series definition. The BusinessEntityID property is placed in the Data Elements section as an NVD3 Pie series using the Count Distinct aggregate.

Elements used within the first widget model

For the 3.EmployeeProvincesChart model, the StateProvinceName property is placed in the Row Elements section. The BusinessEntityID property is used in the Data Elements section with a Count Distinct aggregation as an NVD3 Bar series.

Elements used within the second widget model

The chart configurations themselves are not the focus here; they simply demonstrate how multiple visual components can reuse a shared filtering model.

Visualizing Multiple Models

In the previous posts, we worked with a single model. Now, let’s see how multiple models can be used together within the same report.

In this example, the data table is displayed inside a bottom container, while the top container includes two charts: Employees' Provinces and Top 10 Job Titles.

Report visualization

The following hierarchy is configured within the Views folder:

. View
|__ Widget --Widget view
   |__ 2.EmployeeJobTitlesChart --Model view
      |__ Container --Container view
         |__ Chart NVD3 --Chart NVD3 view
   |__ 3.EmployeeProvincesChart --Model view
      |__ Container --Container view
         |__ Chart NVD3 --Chart NVD3 view
|__ Widget --Widget view
   |__ 1.DataTable --Container view
      |__ DataTable --Data table view
Enter fullscreen mode Exit fullscreen mode

Views folder hierarchy

At this point, each visualization is powered by its own model, but all of them inherit the same filtering logic from the shared model defined earlier.

Top comments (0)