Improve Scalability for Conditional KPI Display

Ask the Community
,
1

Hello everyone,

My Workshop application displays specific KPIs depending on the user’s team. As not every team tracks the same KPI, I use conditional visibility to show or hide sections accordingly. The KPI values are also dynamically computed for each user.

As the number of unique KPIs (and corresponding metric cards) increases, I’m noticing performance issues—especially when loading the module.

I’m interested in hearing about ways to improve scalability from your experience. Has anyone tackled a similar challenge?

I’ve been looking at Loop Layouts, but am struggling with passing variables between module, especially since KPI are not often computed the same way.

Current workflow:
User –> Team –> KPI Definition (Object Set mapping KPI to teams) –> KPI Conditional Visibility

Team –> Filter Relevant Data –> Computation of the KPI Value (object set aggregations)

Any suggestions or best practices would be greatly appreciated!

1 Like
2

My experience has been that whatever you can precompute in Pipeline Builder / Code Repos, you should. Even metrics that require dynamic time aggregations, there are typically “auxiliary” aggregations that you can do beforehand to prevent you from needing complex formulas or even function-backed aggregations in widgets.

You can also leverage restricted views to do group based filtering so you keep the input objects lighter and you don’t have to manage as much logic in Workshop.

Definitely don’t rely on Quiver widgets for anything else than super simple and light calculations / displays, they can balloon your compute time and costs really quickly.