Human Capital Management Blogs by SAP
Get insider info on SAP SuccessFactors HCM suite for core HR and payroll, time and attendance, talent management, employee experience management, and more in this SAP blog.
Showing results for 
Search instead for 
Did you mean: 
With this guide, we wish to address how Report Designers can review their stories created in SuccessFactors People Analytics Report Stories to address Performance Issues that they may have faced. While we cover a good amount of ways to prevent Performance issues by providing design time guidelines in IDP but it is also important to review our stories from a diagnostic lens on what factors could have caused Performance issues 


The following Master Blog would provide a diagnostic framework and an ongoing collection of individual blogs optimizing various areas of Report Stories for necessary Performance improvement. At the same time, we would also use the same to address some of the use cases which may be ideally suited for other People's Analytics tools and not just Report Stories 


We would keep updating the content as and when we publish newer content on the same. Do check out the Master Blog for all the updated content 


Please refer to the following guidance framework for debugging and optimizing Performance as necessary based on issues that are like the symptoms and have underlying causes that need to be reviewed


New Blogs in the series - Released on 12 Dec 2022

New Blogs in the series - Released on 4 Jan 2023


Issues/Symptoms Causes to Review Details
General Story Slowness  Too many widgets in the story The IDP defines the ideal weight-based approach (tested by SAC) to the number of widgets one should have in the story to avoid. Refer to the IDP or SAC Best Practice Document defining the weight-based approach for the number of widgets
Bloated Data Model The data model defined in the query designer should not be bloated or have an unnecessary number of widgets. The report designer should add only columns and object schemas on the need basis and functional design of the story report
Too Many Data Sources Some report designers try to bypass the suggested 120-column limit in the data source by introducing multiple data sources and linking them which in turn can lead to further performance deterioration
Too Much Data Blending While there are scenarios that require data blending, some report designers try to put so much information into a single page leading to unnecessary data blending which can cause problems
Nesting too many Calculated Columns Nesting calculated columns can lead to performance issues as building calculated columns over other calculated columns mean sequential processing leading to a longer time to render. In some scenarios wherever feasible, it is better to build calculated columns directly over source columns rather than building intermediate calculated columns
Too many Self Joins

Some reports require multiple joins to the same object in the query designer. Some report designers use this as a mechanism as a prerequisite to show the transposition of values at the widget in the story  (row level value now being column headers).

This can be achieved by using the cross tab at the story level and still having single schema objects at the query designer layer

We will be adding a detailed blog on the same
Wrong Use Case- Data Dump and SQL Analytics

Some use cases like dumping data to excel or complex window function-based SQL Aggregates are best suited for Workforce Analytics or other SAP tools like SAC Planning. Consult with your CSM and Partner on the same

For the partial export use case of Table Widget data export (for limited data volume), you can refer to the following blog here. [Note: Report Stories is not a Data Extraction Tool]

Alternatively, there is also a scheduling facility for similar export use cases. More details to follow
Slowness in working with filters Improper Use of Filters

There are multiple scenarios with improper use of filters that can cause issues. A few of them to review are as below. We will define some of them below

1) Not using scope filters for providing matrix level filters i.e manager level/ HR level data access

2) Not using schema object level filters before joining 2 schema objects. This is critical to avoid data explosion at the time of data fetched for the query

3) Not using filters on story widgets

4) Using the same filters at multiple places

5) Not using bookmarks features where one needs to work a group of filters with specific values and store those as bookmarks

We will add other blogs on the Filter usage soon
Apply Selection for Filters

Not using the “Apply selection for filters” feature in a Story. This one is a recently supported feature for facilitating multiple value selection in high cardinality filters.

Refer to the blog for more details

High Cardinality Filters High Cardinality Filters take a long time to load as they have a lot of values to load at the time of selection. This can be optimized by reducing some of the not needed values by filtering them at the query level only
Avoid linked Dimension on Calculated Dimension and then adding the same as filters Using a Calculated Column as a Linked dimension can have a performance impact
Story Timeouts and Errors Scope Filtering While a lot of these errors were addressed and resolved in b2205 and b2211, if such issues are still encountered, the best way is to apply proper scope filtering to reduce the amount of data fetched to prevent timeout
Missing RBP permissions Another reason for the widget-specific errors could be the story viewer not having RBP permissions for the specific columns used in the widgets
Authorization Errors Sometimes users are not synced properly due to IDP configuration issues. Do refer to the IDP on the same
 Wrong data or No Data in the widgets MDF Objects unavailable for Reporting

MDF object reporting needs to be reviewed for proper configuration. Please refer following help section on custom MDF object reporting limitations.

Refer to the blog for more details
Table Widget slowness/ failed to load/ widget crash Drill Limitation Removed and 1 million cell limit breach

Currently, there is a limit of 1 million cells for the table widget and in case the drill limitation is set to unlimited and the result set has more than 1 million cells, the query guardrail would kick in and the widget would fail

The best would be to split the table into multiple tables with row-level filters

For a few scenarios, offline scheduling can be considered where the report is a table widget alone
Building Complex Hierarchies via Calculated Columns

Hierarchies are currently not supported in Report Stories. Bypassing the same by building these hierarchies via calculated columns can impact performance and should be avoided

We will be sharing a detailed blog on the topic soon
Chart Widget Slowness Top N filter on high cardinality dimensions Chart widgets using high cardinality dimensions can be slow to run, using the "top N" filter can help improve performance
Imported Stories Fail to Run Content Store Import failure

The following blog provides a comprehensive guide to fixing errors in import.

At the same time do refer to the Query Validation tool for changes in the imported query vs the actual query [Refer to the Blog here for QVT]
Raising Support Tickets for Customer Support to investigate Attach HTTP Archive (HAR) files to debug for Engineering review

For the support team to investigate customer-reported issues, it is best to provide HTTP Archive (HAR) files as attachments while raising a ticket.

Refer to the blog for more details


We will add more individual blogs and update the same framework to ensure up-to-date information for report designers and viewers. Meanwhile, keep checking the master blog for regular updates


Reference Resources 

People Analytics IDP 

SAC Best Practices