eProcureAI / Platform / Dashboard and Role Views
Dashboard and Role ViewsShowing somebody ten times more than they need is the fastest way to make them stop looking. Three views, each scoped to what that person can actually act on.
This is the real screen. Company head, manager and team member views.
The instinct when building a dashboard is to include everything, on the theory that more information is better. In practice it is the reason people stop opening it.
A team member looking at a view containing every request across the company cannot find their own. A manager seeing nine other teams learns nothing they can act on. Both quietly go back to email.
So the views here are deliberately narrow. A team member sees their own work. A manager sees their own team. Only the company head sees everything, because that is the only role where everything is actionable.
For a company head, the question is rarely what was purchased. It is where work is piling up. Which team has requests stacking against a manager who is travelling, and which team is clear.
That is what the team tiles show. Manager, member count, live workload and pending approvals, with a drawer that opens onto the full roster when something looks wrong.
Because access is granted by department, the view somebody gets follows from where they sit rather than from a preference somebody set. Move a person between departments and their view changes with them.
Every team as a tile, showing the manager, the member count, live workload and any pending approvals. The question this answers is where work is piling up.
Clicking a tile opens the full roster with workload per person and the manager highlighted, which is usually enough to see what is happening.
Their own team only. Requests in flight, what is awaiting their approval, and how work is distributed across their people.
Their own requests, what is waiting on somebody else, and what has been delivered. Nothing about colleagues.
Views come from department access rather than a setting, so moving somebody between teams changes what they see automatically.
A manager cannot do anything about another team's backlog. Including it converts a dashboard from a tool into a report, and reports get read once.
Knowing a team raised forty requests tells you little. Knowing eleven are stuck waiting on one person who is travelling tells you what to do this afternoon.
Because scope comes from department access, nobody configures a dashboard and nobody sees the wrong thing after changing role.
The difference is scope rather than capability. Nobody is missing a feature, they are missing noise.
| View | Sees | Does not see | The question it answers |
|---|---|---|---|
| Company head | Every team, manager, member count, workload, pending approvals | Nothing withheld | Where is work piling up |
| Manager | Their own team's requests, workload and approvals | Other teams' work | What needs me, and who on my team is stretched |
| Team member | Their own requests and what is waiting on others | Colleagues' requests | Where did my request get to |
Each view answers one question well, which is a better test for a dashboard than how many numbers it displays.
Counted from live requests rather than entered anywhere, so it is current by definition.
The number most likely to prompt action, which is why it is badged on the tile.
From department membership rather than a separate list somebody maintains.
Also from the access model, so it does not go stale after a reorganisation.
Everything they raised that has not completed, which is the whole team member view.
Useful context rather than a headline, showing the week is progressing.
A dashboard that shows somebody exactly what they can act on gets opened daily. One that shows everything gets opened once.
Open one screen and see what needs them. That is the entire interaction.
Counts live activity and shows each person only the part they can act on.
We will map it and show you what each of the three roles would actually see.
Book your free demoNext in the chain: Access and Permissions