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. It requires using the security model your LMS already has, instead of building a parallel one.
Three patterns that don’t work
Giving managers admin access. Tempting because it’s quick. Wrong because admins see everything: every team’s performance, every learner’s history, and any sensitive profile fields your LMS holds. 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 self-serve. Managers can’t slice the data the way they want, and the data is always a few days old. 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 moves but doesn’t go away.
The pattern that works
Your LMS already knows who manages whom, who’s in which department, and who reports to which organization or position. The right pattern reuses that knowledge to filter what each manager sees.
Build one manager dashboard. When a manager opens it, the 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 own team. Same dashboard, different data, no per-manager configuration.
In Zoola Analytics this is handled with XML security files. The managers.xml file, attached to a data source, restricts any report or dashboard built on that source 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.
A worked example
Say you want to give every people manager a dashboard showing their team’s training status:
- Build (or use the pre-built) manager team rollup dashboard.
- Attach the managers.xml security file to the underlying data source.
- Assign the appropriate Zoola role to your managers in the LMS. This is a one-time admin step per role, not per manager.
- Every manager who opens that dashboard now sees their team, and only their team.
Site administrators still see everything. Nobody else sees anything they shouldn’t. The L&D team is out of the loop, the manager serves themselves, and security holds.
Going deeper: hierarchies of hierarchies
A common request: a VP wants to see their directors’ direct reports too, three levels deep instead of one. managers.xml on its own gives the immediate level. For the deeper view, Zoola supports a documented derived-table pattern (specific to Totara) that walks the manager-employee chain to the depth you need.
This is hard in generic BI tools, where you’d build it from scratch, and much more manageable in a tool built to understand LMS hierarchies.
The other security layer
Row-level security through XML files handles what data you see. Repository permissions handle what content you can 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 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 bigger principle
This works because the security model lives in one place: your LMS. Roles assigned in Moodle or Totara map to data access in Zoola. There’s no parallel user database and no second permission system to keep in sync.
If you’re considering generic BI tools for LMS reporting, this is one of the underappreciated reasons to look at LMS-specific platforms. Building this row-level security in a generic tool is real work, and keeping it in sync with your LMS is ongoing work.
The takeaway
Manager self-serve isn’t a security risk if you use the security model that already exists: row-level security tied to the LMS hierarchy, permissions on the dashboards themselves, and role assignments in the LMS to grant access. Set it up once, and the L&D team is out of the manual-reporting loop.