Defining a reporting strategy

Organizations rely on reporting and business intelligence to make informed decisions. In some scenarios, government and industry standards drive the need for reporting. For example: 

• Executive management requires dashboard reports and key performance indicators (KPIs) to make strategic decisions for the business, monitor the organization's performance, and take action based on that data. 
• Line-level managers need reports to ensure their teams meet business Service-Level Agreements (SLAs). 

When defining a reporting strategy, it is important to inventory the reports that the business uses to make key decisions, which can help determine the overall reporting strategy.

After you inventory these reports, create a matrix that categorizes the user roles and the reports each role uses to make business decisions. For example, you may create throughput reports for various users. 

• Line managers use the reports to show the throughput of team members.
• Managers use reports to optimize the routing of assignments.
• Executives may want to see a summary of throughput over specific periods. The reports enable the executives to drill down into the results of individual departments and plan staffing requirements for these departments in the coming months.
• Individual team members can see their own throughput metrics to gauge how close they are to meeting their own goals and to work toward their incentives.

Identify how often the data needs to be delivered. This information affects configuration decisions such as report scheduling settings, agent schedules, and refresh strategies on Data Pages. Other factors, such as currency requirements, might also play a role in your strategy. For example, you might have a Data Page that contains exchange rates, and this data requires hourly updates. In this example, the report that sources the Data Page requires a refresh strategy. 

Data storage and availability are also important considerations related to frequency. The answer to these questions influences how you architect a data-archiving or table-partitioning approach. Implementing a data-archiving strategy and partitioning tables can help improve the long-term performance of your reports.

This question is related to who needs the data and what the purpose of the report is. Existing reporting requirements influence what data the report must contain. When you research the need for each report, you might find that some of the report data is unnecessary. For example: 

• You might discover that no one in the organization reads the report or uses the report as the basis for any decisions.

On the other hand, you might find opportunities to provide new reports. For example:

• A department cannot create a necessary report because the current business process management system cannot extract the data.

Pega Platform offers several options for gathering report data within the application. The strategy that you recommend depends on the reporting that you are doing.

• If the organization requires heavy trending reporting and business intelligence (BI) reporting, a data warehouse might be a better fit.
• If you want to display the status of work Assignments on a dashboard in the application, report definitions with charting are appropriate.

When you access data for reports, you need to know which table has the data and how the system maps it. You want to join multiple tables to access the data in some situations. Pega Platform provides different options for the data, such as join, association, declare index, and subreport options. As a Lead System Architect (LSA), you must decide which joining mechanism performs better to extract the required information. For example, use:

• Case and Subcase relationships to show Subcase data along with the parent Case data.
  • List the purchase orders in a purchase request. You match the Case identifier in the parent purchase order class to the Case identifier in the child purchase request class.
• Case and Assignment relationships to show how the system processes Assignments for a specific Case or a Subcase.
  • Show the operators working on specific Case. You match the operator identifier in the database table of the Case with the operator ID column in the Assignment table.
• Case and history relationships to monitor performance.
  • Show the total amount of time required to resolve specific Cases. You match the Case identifier in the data table of the Case with the Case identifier in the history table.
• Subreports
  • Subreports can use class definitions that are different from definitions of the main report.
  • Subreports can help to filter results. This approach allows you to include or exclude data.
  • Subreports can help to display aggregate calculations on specific rows in a list report.

While Pega Platform offers robust reporting features, it is important to consider alternative approaches to traditional reporting and data warehousing. These approaches may be the best way to meet your reporting requirements. For example, you can use robotic automation to gather data from external desktop applications. If you use data for analytics, consider using adaptive and predictive Decision features. If you need dynamic queries, you can also use freeform searching on text, such as Elasticsearch, instead of constructing a report definition to gather the data. With the increasing popularity of big data and NoSQL databases, freeform search is becoming more common. 

Pega Platform provides a comprehensive set of data extraction features to support different reporting scenarios. Understanding these options helps Lead System Architects (LSAs) design data integration strategies that balance performance, timeliness, and technical complexity.

Small-volume ad hoc data: Insight export to Excel

For quick access to operational data for ad hoc analysis, use the Export to Excel feature in Insights. This feature allows you to:

• Export the current view of an Insight, including applied filters and calculations
• Perform additional analysis in Excel without technical expertise
• Share data snapshots with stakeholders outside the Pega application

Use this approach for one-time analyses or when formal reporting processes are unnecessary.

Mid-scale data: Business Intelligence Exchange (BIX)

For structured and recurring data extraction, use Business Intelligence Exchange (BIX). BIX supports batch extraction in multiple formats:

• XML for structured data exchange
• CSV for importing into analytical tools
• Database schema formats for direct database integration

BIX supports scheduled and on-demand extractions. Use BIX for regular reporting cycles and when integrating Pega data with enterprise data warehouses or business intelligence platforms.

High-volume data: Change Data Capture (CDC) and Data Flows

For enterprise-scale reporting and integration, use one of these options:

Change Data Capture (CDC) provides real-time data extraction by:

• Capturing data changes as they occur in the Pega database
• Streaming changes to target systems with minimal latency
• Supporting event-driven architectures and real-time dashboards

Data Flows provide batch or real-time extraction with transformation and enrichment by:

• Supporting complex data transformations during extraction
• Enriching Pega data with information from other sources
• Offering flexible scheduling options for batch processing

Selecting an extraction method

When selecting an extraction method, consider:

• Volume of data to extract
• Frequency requirements (real time, hourly, daily)
• Transformation needs before data reaches target systems
• Technical capabilities of the receiving systems

A well-designed extraction strategy often combines multiple approaches, using lightweight methods for operational reporting and robust solutions for enterprise analytics.

Pega Platform includes enhanced native reporting features. However, some scenarios require external business intelligence (BI) tools. Use this decision framework to evaluate reporting requirements and select the most effective approach.

Use Pega Insights and Reporting when:

Data source characteristics

• Most or all required data resides in Pega applications.
• Data relationships are modeled within the Pega application.
• Real-time access to operational data is required.

Reporting requirements

• Operational reporting is the primary need.
• Reports must be embedded in Pega applications.
• Interactive features such as filtering and drill-down meet requirements.

User considerations

• Users need intuitive, self-service reporting with minimal training.
• Report consumers primarily use Pega applications.
• Role-based security is configured in Pega.

Technical factors

• Interactive drill-down and visual customization meet requirements.
• Report volumes and complexity are supported by native reporting features.

Use external BI tools when:

Data integration complexity

• Large datasets require joins across Pega and non-Pega sources.
• A complex data warehouse architecture exists.
• Historical data spanning multiple years must be analyzed with current data.

Advanced analytical needs

• Advanced geo-spatial analysis is required.
• Sophisticated statistical analysis beyond basic aggregations is needed.
• Predictive modeling must integrate with reporting.

Visualization requirements

• Highly customized visualizations beyond Pega charting features are required.
• Interactive dashboards need advanced features such as parameter-driven reports.
• Complex visual analysis and querying exceed current Pega capabilities.

Enterprise considerations

• Enterprise standards mandate a specific BI platform.
• Integration with multiple external data sources is required.
• Specialized reporting skills exist for specific BI tools.
   

Check your knowledge with the following interaction: