How to Link Multiple Data Providers in a Fixed Layout Report

Products

• Clarity PPM SaaS
• Clarity FedRAMP
• Clarity PPM On Premise

Issue/Introduction

When designing a Fixed Layout report that uses multiple data providers, it is common to encounter a scenario where one data provider retrieves the primary object (for example, Projects/Investments), while another retrieves related child records such as Risks, Issues, Milestones, or Status Reports.

Without proper configuration, child data may display incorrectly across all report pages instead of being filtered to the current project context.

Example Scenario

Consider the following reporting setup:

Data Provider 1 (Primary / Parent Data)

The first data provider retrieves project-level information from the Investment object, such as:

• Project Name
• Project ID
• Stage
• Status

It may also include additional query logic, such as retrieving the current and previous status report RAG values.

This data provider returns multiple projects based on selection criteria and establishes the primary reporting context.

Data Provider 2 (Related / Child Data)

The second data provider retrieves related records, such as:

• Risks and Issues
• Key Milestones
• Status updates
• Other project-related lists

For example, the query may order results to display high-priority Issues first, followed by Risks.

This data provider also returns multiple projects and includes the Investment object as part of its query.

Environment

Clarity All Supported Version

Cause

In a Fixed Layout report, placing fields from Data Provider 1 (DP1) establishes the master record context for the report canvas. The report engine loops through DP1 and generates one page (or section) per project.

However, widgets that use Data Provider 2 (DP2) operate independently unless explicitly linked to the current project context.

As a result:

• DP1 renders one project at a time.
• DP2 executes its query independently.
• All child records returned by DP2 may appear on every page.

For example, a Risks table could display risks from every project rather than only the current project being rendered.

Resolution

To associate the two data providers, configure a widget-level filter on the child widget so it dynamically filters records based on the current project context.

Steps to Configure the Filter

1. Open the report template in Report Designer.
2. Select the widget that displays child data (for example, the Risks/Issues table using DP2).
3. Open the Filter tab in the widget configuration panel.
4. Add a new filter using the project reference field from DP2, such as:
   • Investment ID
   • Project ID
   • Investment Internal ID
5. Set the operator to: Equals
6. Configure the filter value as a dynamic field/context value rather than a static value.
7. Select the matching unique identifier from DP1, such as:
   • DP1.ID
   • DP1.Investment ID

Example Logic

Conceptually, the filter works as follows:

DP2.ProjectID = DP1.ProjectID

This ensures that when the report renders:

Project A → only Project A child records display

Project B → only Project B child records display

The child widget dynamically inherits the current project context during report generation.

Additional Information

Using the Out-of-the-Box Sample Report as a Reference

An effective way to validate the configuration is to review the Sample Project Status Report, which already demonstrates this behavior.

How to Review the Configuration

1. Open a copy of the Sample Project Status Report in Report Designer.
2. Select a child widget such as:
   • Key Milestones table
   • Risks chart
3. Open the widget’s Filter tab.
4. Review the attribute mapping used to bind the widget to the primary project data provider.
5. Replicate the same filter structure in your custom report using the equivalent ID fields from your data providers.

Best Practice

When using multiple data providers in a Fixed Layout report:

• Use one data provider to establish the parent/master context.
• Configure widget-level filters for all child datasets.
• Match child records using a unique project identifier.
• Validate the setup against out-of-the-box sample reports where applicable.

This approach ensures that related data is rendered only for the active project and prevents unrelated records from appearing across report pages.