Who Should See Customer-level Detail in a Dashboard?

Imagine a multi-team property services company handling this situation. A manager shares a useful workload dashboard with the whole company.

It also reveals customer contact notes that most viewers do not need. This fictional situation could begin with a perfectly sensible shortcut. The difficulty emerges when more people rely on the result, because an informal understanding is no longer enough to support the next decision. It helps to examine what the next person needs, rather than simply adding another notification.

Summary reporting and record-level access have been designed together without considering different audiences.

A manager may need a summary without every viewer needing the same personal detail. Access decisions should follow the intended task, including export and sharing routes.

The access review should include the route from a summary to individual records. A viewer may legitimately see total workload without needing customer contact notes. Exports, subscriptions and forwarded links should follow that same decision instead of becoming a less controlled way around it. This matters because the next person sees the record rather than the conversation behind it. If important meaning lives only in an email or somebody's memory, an apparently straightforward action requires another round of checking before it can proceed confidently.

Create views around decisions and limit detailed drill-down to authorised roles. Test exports and shared links as well as the visible screen.

Agree the time window, record level and important exclusions before choosing visualisations. Where information is combined, check how missing, repeated or late records affect the result. Write down the decision the report is meant to support and the records included in its measure. A useful report makes its limitations understandable alongside its numbers. A dashboard should let an authorised reader trace a surprising figure back to relevant source information. Keep unavailable information distinct from a measured result so a reassuring display does not hide uncertainty. Existing reporting features may be sufficient once the definitions are made consistent.

Removing a column from the screen does not necessarily remove it from an underlying export or data connection.

For background relevant to dashboard access boundaries, see What Should a Small Business Dashboard Actually Show. The issue here is the narrower workflow described in this example.

Open the report as a field employee, a team lead and an external viewer with no access. Observe the process with somebody who performs the task regularly. Ask them to use representative records and explain which information they trust before proceeding. Compare that explanation with what the proposed workflow actually records and makes visible to the next person.

For dashboard access boundaries, review the proposed outcome with the staff responsible. Trace a surprising result back to its included records and definition. Check that the person reading the view can distinguish a genuine result from missing or incomplete information, and that the report supports the intended decision rather than merely displaying data. Before expanding the change, check whether staff can identify and correct an unsuitable result. A small reliable adjustment is more useful than a wider process that nobody can safely maintain.

At Software Logic, we explore how business reporting can support everyday work, including the decisions that should remain with the people responsible. Which details does each dashboard viewer actually need to make their decision?