Making a KPI dashboard show each user only their own patch

Context

Performance Buddy is a near real-time Retail Banking KPI dashboard. It replaces manual Excel reports and brings data-warehouse and Pi360 metrics into one role-based view, so each user sees the performance figures for the part of the Bank they are responsible for.

Two teams shape what it shows. The Data Management Office supplies the data sources. Financial Control (FINCON) owns the targets and the financial metric definitions, and validates the figures against FinTrak data. I took over the project as Project Manager and Business Analyst in 2026, and it is still in progress.

The problem

A role-based view is only as good as the rule that decides each user’s role. The obvious source for that rule was the company directory (Active Directory). But the directory confirms who a user is; it cannot express the Bank’s business hierarchy, such as who leads which region, group or division.

That gap showed up in two ways:

• Senior leaders defaulted to bank-wide visibility. With nothing in the directory to narrow their view, the simplest rule gave them everything.
• Leaders’ branch codes pointed to the wrong place. In the directory, a leader’s branch code reflected their HR cost centre, not the area they actually manage. A rule built on it would show a leader someone else’s patch.

For a dashboard of performance figures, either outcome is a problem. Users need to see their own area, all of it, and nothing they shouldn’t.

What I did

I wrote the authorisation requirements and an architectural brief for the developers. The core of both is one idea: keep authentication and authorisation apart. The directory answers “who is this?”; business data answers “what may they see?”.

1. Defined a cascading access check. Four steps, tried in order, and the first that matches decides:
   1. The leadership mapping table, looked up by the user’s email. It gives a region, group or division, or bank-wide for executives.
   2. Branch managers, identified by job title and restricted to their branch.
   3. Account and relationship officers, restricted to their own portfolio by staff code.
   4. Everyone else gets no access by default.
2. Put the changing data with the people who change it. The hierarchy data comes from the Data Management Office, and the business maintains the leader table. When a leader moves, someone updates a table; no one changes code.
3. Found a data quality fault before it reached users. Branch and staff codes from the directory carried stray spaces. Those would break the data joins and return empty dashboards. I specified trimming at the point of capture, so the codes are clean before any join uses them.
4. Added a “drill down only” rule. Users can view only the levels below their own.

Techniques: authorisation requirements, decision logic and decision tables, data quality analysis and an architectural brief.