Managers want their own dashboards. Usually, the answer is no — and usually, the reason is data security. A dashboard that shows team performance is useful to a manager. A dashboard that accidentally shows another team’s performance is a problem.
Most organizations resolve this tension by not resolving it. Managers send requests to the L&D team. The L&D team produces filtered exports. The exports go stale. Managers stop asking. Insights stop happening.
There’s a better pattern, and it isn’t rocket science. It just requires using the security model your LMS already has, instead of trying to build a parallel one.
Before getting to what does work, it’s worth being explicit about what doesn’t.
Giving managers admin access. Tempting because it’s quick. Wrong because admins see everything — every team’s performance, every learner’s history, every salary detail if your LMS profile fields include it. This is how data leaks happen. It’s also a problem at audit time when the access logs show fifty managers with admin rights.
Sending weekly PDFs. Better than nothing but not actually self-serve. Managers don’t get to slice the data the way they want, and the data is always a few days stale. The L&D team becomes a dashboard delivery service.
Building each manager their own report. Doesn’t scale. Every change request goes back to L&D. Every new manager needs a new report. The bottleneck just moves.
Your LMS already knows who manages whom, who’s in which department, who reports to which organization or position. The right pattern is to reuse that knowledge to filter what each manager sees.
Concretely: build one manager dashboard. When a manager opens it, the underlying data is automatically filtered to their direct reports — based on the manager-employee relationships already in the LMS. When a different manager opens the same dashboard, they see their team. Same dashboard, different data, no manual configuration per manager.
This is how Zoola Analytics handles it via XML security files. The managers.xml file, attached to a data source, ensures any report or dashboard built on that data source automatically restricts to the manager’s direct reports. The departments.xml file does the same for department membership. For Totara, organizations.xml and positions.xml use the position and organization hierarchy.
Say you want to give every people manager a dashboard showing their team’s training status. The pattern looks like this:
Site administrators still see everything. Nobody else sees anything they shouldn’t. The L&D team is no longer in the loop. The manager serves themselves. Security holds. Audit-friendly.
A common request: a VP wants to see their directors’ direct reports too — three levels deep instead of one. Pure managers.xml gives the immediate level only. For the deeper view, Zoola supports a documented derived-table pattern (specific to Totara) that walks the manager-employee chain to whatever depth you need.
This is the kind of thing that’s hard in generic BI tools — you’d have to build it from scratch — and reasonably straightforward in a tool that’s built to understand LMS hierarchies.
Row-level security via XML files handles “what data do you see.” Repository-level permissions handle “what content can you access.” The two work together.
The Zoola repository supports per-folder, per-dashboard, and per-report permissions: No Access, Execute Only, Read Only, Read+Write, Read+Delete, and full Administer. Combine the two layers and you can express almost any access policy. Managers can run the team dashboard but not edit it. The L&D team can build new reports but only see their own department’s data. Site admins see everything.
The reason this works is that the security model lives in one place: your LMS. Roles assigned in Moodle or Totara automatically map to data access in Zoola. There’s no parallel user database, no second permission system to keep in sync, no weekly check to make sure last month’s role changes propagated.
If you’re considering generic BI tools for LMS reporting, this is one of the underappreciated reasons to look at LMS-specific platforms instead. Building this row-level security from scratch in a generic tool is real work — and keeping it in sync with your LMS is ongoing work.
Manager self-serve isn’t a security risk if you use the security model that already exists. The pattern: row-level security tied to the LMS hierarchy, plus per-artifact permissions on the dashboards themselves, plus role assignments in the LMS to grant access. Set it up once, and the L&D team is out of the manual-reporting loop.