Delphi uses two independent access controls that work together: role-based scope, which determines what a person can do, and data classification, which determines what a person can see. Both are enforced on the server on every request, and both fail closed — if Delphi cannot confidently confirm access, it denies it. That means you can invite the whole company without worrying about accidental exposure of sensitive data.
The six roles
Every dashboard member is assigned exactly one of six roles. Higher roles always inherit the capabilities of lower ones.
Owner. Full control over the command center, including deleting the dashboard, transferring ownership, and managing billing. Owners can see every classification including restricted data.
Admin. Everything an owner can do except delete or transfer the dashboard. Admins manage permissions, generate and revoke API keys, configure MCP sessions, and see every classification including restricted data.
Editor. Full day-to-day operational access. Editors can create and modify datasets, visualizations, connectors, KPIs, scenarios, agents, and reports, and can use every chat tool including mutating ones. Editors see public, internal, and confidential data, but not restricted data.
Analyst. Read-only plus query tools. Analysts can explore data, run chat queries, build scenarios in draft, and export reports, but cannot mutate the underlying dashboard. Analysts see public and internal data only — confidential and restricted are hidden.
Auditor. Read-only plus the full audit trail. Auditors exist specifically for compliance reviewers and internal audit teams: they can see public, internal, and confidential data (enough to verify controls), but never restricted data, and they cannot change anything. This sits deliberately between viewer and analyst on the scope ladder — less operational reach than an analyst, but broader data visibility for audit purposes.
Viewer. Read-only access to public data only. Ideal for stakeholders, external partners, or anyone who only needs to watch headline metrics without touching anything sensitive.
Data classification levels
Every dataset, connector, document, and KPI in Delphi carries a classification tag that determines who can read it.
- Public. Non-sensitive information appropriate for any dashboard member or external stakeholder.
- Internal. Information appropriate for employees and trusted collaborators, but not for unauthenticated or external audiences.
- Confidential. Sensitive business data, HR-adjacent records, or personal information that should only reach people with a clear operational or audit need.
- Restricted. The most sensitive tier: regulated data, secrets, legal holds, or executive-only material that even editors should not touch.
Items without an explicit classification are treated as public for backward compatibility, but unknown or misspelled classifications are denied outright.
How they combine
Access to any item in Delphi requires two checks to pass. First, your role must meet the minimum scope for the action (for example, editing a dataset requires editor or higher). Second, your role must be allowed to see that item’s classification (for example, viewers cannot read internal data even if they technically have read access to the dashboard).
Both checks are enforced every time — there is no cached “approved” state that survives a role change. Revoking a role or lowering a classification takes effect on the next request. And because Delphi is fail-closed, a typo, an unknown classification, or a missing permission record all produce the same answer: denied. Every role change and permission update is recorded in the audit log, so you can always reconstruct who had access to what and when — see the audit log guide for how to review that history.
Sharing with everyone in your organization
Alongside per-person invitations, each dashboard has an organization-wide setting: share it with everyone in your organization and colleagues get access without being invited individually.
“Everyone in your organization” means people whose verified work email is on one of your organization’s domains. It deliberately does not include external collaborators — a contractor, a partner, an auditor invited to one dashboard on their own address. They keep exactly the access you gave them and pick up nothing from organization-wide sharing. Your tenant administrator sets which domains count as yours; if none are configured, anyone signing in to your tenant with a verified email qualifies.
You choose which role they get. Viewer suits a dashboard you want widely read but not touched; editor suits a workspace your own team is meant to work in together. The setting stops at editor — no organization-wide share can hand out admin or owner, because those roles manage access itself and should always be granted to named people.
Raising the shared role above viewer takes a tenant administrator, on the reasoning that widening what a whole organization can do is a different decision from sharing a dashboard at all. Lowering it, or turning sharing off, stays with the dashboard owner.
The organization-wide role is a floor, not a ceiling. Name someone as an editor on a dashboard shared organization-wide as viewer and they keep editor. Name someone as a viewer on a dashboard shared as editor and they get editor too — the wider share already gives it to every colleague, and adding someone by name shouldn’t quietly take it away. Whichever is higher wins, which is the same rule the parent/child cascade follows.
If you need someone held below the organization-wide role, the setting itself is the thing to change: lower the shared role, or turn sharing off and invite people individually.
The floor also applies down the hierarchy, and this is the one place it will stop you rather than simply grant access. Organization-wide sharing set on a parent reaches every initiative beneath it, and an initiative can neither turn it off nor lower the role it grants — both attempts are refused rather than quietly ignored, because a child that looks private while its parent shares it with everyone is worse than being told no. Change it on the command center that set it and the whole tree follows.
Who can create command centers
Creating a new command center is controlled at the organization level, not by the six roles above. The six roles govern what you can do inside a dashboard you have access to; whether you can start one of your own is a separate setting your tenant administrator controls.
They’re worth keeping straight. Someone can be a viewer on your command center — read-only, public data only — and still create their own command centers, if your organization allows that. It doesn’t give them any additional access to yours: creating a child initiative underneath an existing command center requires editor on the parent, and that rule isn’t affected by the organization-level setting.
If you’d rather only administrators create command centers, ask your tenant administrator to turn open creation off.
How permissions inherit across command centers
Command centers nest. Grant someone access to a parent and they pick up the same access on every initiative beneath it — children, grandchildren, the whole subtree. You don’t have to walk the tree and add them to each one.
Inheritance is monotonic: a child can be granted more than its parent (an analyst on the parent who needs editor on a single child, for example), but never less. If you want to keep someone out of a specific child, you cannot do it by lowering their role there — you revoke at the level where the grant originates. This is the same rule that applies to public visibility, organization-wide visibility, and API keys, so the cascade behaves consistently across every sharing surface.
Organization-wide sharing follows that rule too. Share a command center with your organization as editor and every initiative beneath it is shared as editor. A child can be raised higher on its own, but it cannot opt down: if you need a corner of the tree shared more narrowly, change it where the sharing starts, and Delphi will point you at that dashboard rather than silently applying a change that wouldn’t hold.
Choosing the right role
Start from the principle of least privilege: give each person the lowest role that lets them do their job, and promote later if needed. Most operators should be editors, most executives and stakeholders should be viewers or analysts, and only a small handful of people should hold admin or owner. Reserve auditor for people whose entire job is verifying controls, not running the business.
When you are ready to bring people in, head over to the invite your team guide for the step-by-step invitation flow.