Access Control¶
Dataface Cloud
This page describes Dataface Cloud, the hosted
product — these features are not part of the open source dft
engine.
Dataface Cloud governs who can see and edit dashboards the same way you already think about shared folders: where a dashboard lives decides who can see it, unless a more specific rule says otherwise. Sharing a folder shares everything in it; sharing one dashboard inside that folder narrows or widens access for that dashboard alone.
All access changes happen in Cloud — never in git. A dashboard's YAML never
carries a permission field, and no _cloud.yaml or similar file records who
can see it. Cloud is the single source of truth for access, and its admin
surface and audit trail are where you go to read or change it.
The filesystem mental model¶
Think of your project like a shared drive:
Grant the finance team access to the finance/ folder, and every dashboard
inside it — present and future — is visible to them. Move
quarterly_summary.yaml into public-reports/, and it picks up that folder's
access, the same way moving a file into a different Drive folder changes who
can open it.
The key Cloud binds access to is a dashboard's path: its file location
relative to the project root, with the file suffix stripped
(finance/revenue_exec, not finance/revenue_exec.yaml). Folders are keyed
with a trailing slash (finance/). The branch a dashboard happens to live on
is never part of that key — access to a path is the same whether you're
looking at the trunk branch or a preview of a feature branch.
Longest-prefix resolution¶
A dashboard's effective access is resolved by walking from the broadest scope to the most specific:
- The project's default access — the broadest scope, what everything in the project inherits absent a more specific rule
- Each directory the dashboard's path passes through, outermost to innermost
- The dashboard's own exact path, if it has a specific grant
Each more specific scope either replaces the access inherited from above it, or adds to it — that's a choice you make when you grant access at a given path, not a fixed rule. "Share this folder with Alice in addition to whoever can already see it" and "restrict this one dashboard to Alice only" are both ordinary grants; they just differ in whether they inherit from the parent.
Because resolution is purely path-based, a new dashboard needs no setup to
have sensible access: drop it in finance/ and it inherits finance/'s
access immediately. Nothing needs reconciling.
Roles as entitlement atoms¶
Access grants pair a principal (who) with a role (what) at a path:
- Principals — an individual, a group, a group synced in from your identity provider, everyone authenticated in your organization, or "everyone" (anonymous, public visitors — see Public access below).
- Roles are built from a small set of underlying capabilities: viewing a dashboard, editing it (which covers creating, saving, promoting, moving, and deleting), triggering a refresh, managing who else has access at a path, managing data source connections, and browsing raw data directly. The built-in roles are Viewer (view only), Editor (view, edit, refresh), and Admin (view, edit, refresh, and manage access) — and custom roles can be composed from the same underlying capabilities for finer-grained needs.
Being able to create dashboards in a folder is just holding an Editor-level grant there — there's no separate "creator" concept. Whoever can edit a path can also create new dashboards under it.
Membership in your organization is a separate axis from dashboard access: being a member doesn't automatically grant view or edit rights to any dashboard. Organization-wide visibility is an explicit grant — "every member can view this project" — not an implicit consequence of joining.
Public access — org and project opt-in¶
Public access has no per-dashboard flag. It's the same mechanism as any other grant: the "everyone" principal gets a Viewer role at a path, and anonymous visitors resolve as that principal.
Because any path is one grant away from being reachable by anyone, public access is additionally gated by two independent switches, both off by default:
- An organization-level switch — the outer gate. Off means no project in the organization can serve anything publicly, no matter what any project or dashboard is configured to do.
- A project-level switch — the inner gate. Off means that project serves nothing publicly, even when the organization allows it.
Both must be on, in addition to an everyone-principal grant on the path, for a dashboard to actually be reachable without logging in. This makes a strict, nothing-is-public posture the default, and turning on public access a deliberate act at each level rather than something that happens by accident. Cloud also won't let you add a new public grant on a path while either switch is off — you can't opt a dashboard into public access the gates don't yet allow. Either switch is an instant kill switch: turn one off and every path under it stops being served publicly, no matter what grants exist. Those grants aren't deleted — they're held inert while the switch is off, and flip the switch back on and they apply again with nothing to re-create. The admin surface makes this auditable: the organization view lists the projects that have opted in, and a project's own settings show which dashboards its grants would expose publicly — even while that project's gate is closed, so an inert public grant is never a blind spot. Flipping either switch is itself recorded in the audit trail, at whichever level was toggled.
Drafts¶
A draft dashboard lives in a private working area, visible only to the person who created it — no grant or public setting on the rest of the project reaches into it. Promoting it to a destination path re-checks access at that moment: the person promoting must be allowed to edit the destination, or it stays a draft. Once promoted, it takes on that path's access like any other dashboard living there.