Hierarchical access
Each person sees the rows their place in the sales structure allows. Benchmarks widen that view to the whole sales team, with no hand-kept list.
The problem
A salesperson may see only their own area, and a regional manager only their region. But salespeople also needed to compare their numbers with the rest of their sales team. And access depended on an exact match of the username. That caused two problems: data that silently disappeared, and access tables far bigger than they needed to be.
Constraints
- Access must follow the sales structure, and change when people move.
- A comparison must not need a list that someone keeps by hand.
- Apps in production must keep working while the access model changes.
What was built
Rows that follow the sales structure. Sales are split into regions, and each region into areas. Every row carries tags for country, business unit, brand and area. A salesperson sees their own area. A regional manager sees every area in their region. The country head sees the whole country. This part was already in place, and the new design builds on it, with a few fixes. Which columns a user sees is a separate check, covered in Data protection and privacy model.
Benchmarks. A benchmark widens a salesperson’s view beyond their own area. It shows every area that their sales team covers in the same country. A sales team can cover areas in more than one region, so the benchmark can reach past the salesperson’s own region. The sales structure drives it, so nobody maintains it by hand.
Own view, area 2
Sales team A
Sales team B
Benchmark view, area 2
Sales team A
Sales team B
One identity per user. Several spellings of each username were stored, because only an exact match worked at sign-in. One exact name, taken from active sign-in accounts, replaced them. A wrong capital letter can no longer hide a user’s data. The change was also part of a cloud cost effort. Each user now has one entry in place of several. So search indexing needs less compute, and the index and the disk need less storage.
Several spellings per user
| Stored name | Works at sign-in? |
|---|---|
| ALEX1 | No |
| Alex1 | No |
| alex1 | Yes |
One exact name per user
| Stored name | Source |
|---|---|
| alex1 | Active sign-in accounts |
Key decisions
- Derive, don’t maintain. Benchmark scope comes from the sales structure. A hand-kept list would drift.
- One identity, from one source. The username comes from the list of active sign-in accounts, not from whatever each system stored.
What to do differently next time
Test for “this user sees nothing” from the start. An exact-match rule fails silently: the user gets an empty screen, not an error, and an empty screen looks like no data.