Access control: users, groups and scoped views

Access · users, groups, dashboards and grids, capabilities

• GroupsPermissions set once3 groups
  • Sales teamSales dashboard · Orders grid · AI Assistant
    • Scoped viewSales dashboard · North regionNorth users only
  • OperationsUrgent orders · Rejected orders · export
  • ManagementAll dashboards · AI Assistant · export
• UsersAdded to a group, or set individuallyinherit the group's access
• AdministrationA capability, not a groupthe few who manage access

Not everyone needs to see everything

A shared data layer is a strength right up to the moment every user can open every dashboard. Then the sales team scrolls past the finance grids, the warehouse sees margin, and the one dashboard that matters to each person is buried in forty that do not. Access control is not only about keeping data from people who should not see it. It is about keeping the screen relevant to the person in front of it.

Access by user

At the finest grain, each person gets a list: these dashboards, these data grids, and these capabilities. The capabilities are the part people forget. Being able to open a dashboard is one permission; being able to export the data behind a widget is another; being able to ask the AI Assistant is a third; administering access is a fourth. A regional manager might have all of the first three and none of the fourth. Keeping them separate is what lets a team see a dashboard without being able to walk away with its data.

Separating capabilities from access also answers the awkward requests cleanly. "Can the intern see the dashboard?" Yes, without export. "Can the partner use the assistant?" Not until the data they can ask about is scoped. Each request becomes a line in a list rather than a judgement call, and the list is the same for everyone in the same role.

Groups: set it once

Per-user lists do not survive the first reorganization. Groups do. Create a group for a team or a role - sales, operations, management - define its dashboards, grids and capabilities once, and add people to it. A new hire joins the group and has the right access on day one; a transfer moves groups and loses what they should lose. The access model becomes a description of the organization rather than a list of exceptions, and the list of exceptions is where access control goes wrong.

• Userjoins→
• GroupSales teaminherits→
• Dashboards · gridsthe relevant ones+→
• CapabilitiesAI Assistant · export

Groups also make audits answerable. "Who can see margin?" becomes "which groups have the finance dashboard", a question with a short, checkable answer. Per-user lists turn the same question into a survey. For a security review, the difference between the two is the difference between an afternoon and a week.

Scoped views

Sometimes the right access is not a different dashboard but the same dashboard, narrowed. The North sales team should see the sales dashboard - the same KPIs, the same charts, the same definitions as head office - limited to the North region. A scoped view does that: one configuration, filtered to a scope, assigned to the users or the group it belongs to. Everyone is looking at the same definition of an order, so the regional 395 and the national 952 are the same count sliced differently, and a conversation between the region and head office starts from agreement.

Scoping matters most where the audience is outside the company. A partner or a dealer given a dashboard of their own performance should see exactly their own slice of the same definitions everyone else uses - and nothing else. A scoped view assigned to a partner group does that without a separate build per partner, which is what makes partner dashboards possible at all.

What can be assigned

Scope and definition are deliberately separate. The scope says which records a view covers; the definition says what the numbers mean. Changing the definition of an urgent order changes it for every scoped view at once, which is the point: a region cannot drift into its own idea of urgent, and head office cannot change the rules without every region seeing the change.

Keeping access relevant

Review groups when the organization changes, not when something goes wrong. Give capabilities as narrowly as the job allows: export to the people who reconcile, administration to the people who manage access. And prefer a scoped view to a copied dashboard every time, because a copy drifts and a scope does not. A good access model is one where the screen each person opens contains only what they use, and where nobody has to remember who was given what. Runs in your infrastructure covers the layer underneath this one: where the data itself lives.

Related

EXPLAINER White-label analytics Your logo, your colours, your theme, on dashboards your teams and customers open every day. The vendor stays invisible unless you want it seen. COMPARISON Delivered analytics vs self-serve BI Self-serve BI hands the team a tool and asks them to build. Delivered analytics hands them the dashboards, configured to the business, ready to use. EXPLAINER Runs in your infrastructure: what that means in practice On your servers or in your private cloud, nothing hosted by the vendor, your keys. A phrase every vendor uses, and six things to check before believing it.