Administer access from the CLI¶

Platform (dbtCharts.com)

This page describes dbt Charts Platform, the hosted product at dbtCharts.com. These features are not part of the open source dct engine.

Everything the Access settings pages do is also a dct cloud verb, so a script, a CI job, or an agent can answer "can Sam open finance?", onboard a team to a folder, or export the audit log without a browser. Each verb calls the same Platform API the pages use and gives the same answer; see Access control for how grants, inheritance, and public access work.

Every verb takes --json (the raw API response), --org, and --host. Verbs that act on a project also take --project. audit export always prints JSON or CSV, so it takes --format instead of --json.

Who can run what¶

A token's scope is a ceiling: the person who signed in must also hold the role the verb needs (org admin for all but comments). dct cloud login asks for all of these; sign in again to add the comment scopes to an older token.

Scope	Verbs
`orgs:admin`	`access list`, `check`, `grant`, `revoke`, `remove-here`, `restore`, `inherit`, `stop-inheriting`, `general`; `public`; `member show`; `audit list` and `export`; `team`; `role`; `identity groups`
`connections:admin`	`connection access list`, `grant`, `revoke`
`comments:read`, `comments:write`	`comments list`; `comments add`, `reply`, `edit`, `resolve`, `reopen` (any member who can comment, not only admins)

Who may open a board is an organization matter, so every access verb needs orgs:admin; the projects:admin scope covers project settings only.

A verb the token's scope does not cover fails with a 403 naming the scope.

Check who can open what¶

dct cloud access list --project analytics --who sam@acme.com
dct cloud access check --project analytics --who sam@acme.com --path finance/revenue

--who is an email, a team slug, or group:<id> for an identity group, exactly what the Check access page accepts. access check prints the verdict and the grants behind it, and its exit status says the answer:

Exit	Meaning
0	allowed
1	denied
2	the check could not run (bad project, unknown person, no credential)

access list narrows like the Grants page: --project, --who (an email, a team slug, or group:<id>), --role, and --public. member show <email> prints a member's teams, identity groups, grants, and every board they can open.

Change access¶

Verb	Effect
`access grant --who W --path P --role R`	Give W a role at P
`access revoke --who W --path P`	Take back the grant W holds directly at P
`access remove-here --who W --path P`	Remove W's access at P, inherited access included
`access restore --who W --path P`	Undo `remove-here`
`access stop-inheriting --path P`	P keeps who can open it now; later changes to its parent folders stop reaching it
`access inherit --path P`	P inherits its parent folders' grants again
`access general restricted\\|org\\|public --path P`	Pick who beyond the named grants can open P

When revoke or remove-here takes the last grant off a path that stopped inheriting, the path goes back to its parents' grants and the command prints an Access now follows … line saying who can open it.

A blank --path is the project root; a folder ends in /. general org lets everyone in the organization view P; general public lets anyone with the link view it and needs both public gates on:

dct cloud public list
dct cloud public allow                      # the organization's gate
dct cloud public allow --project analytics  # one project's gate

Teams, roles, identity groups, connections¶

dct cloud team create "Revenue Ops"
dct cloud team add revenue-ops --member sam@acme.com
dct cloud role create analyst --name Analyst \
  --entitlement dashboards.view --entitlement dashboards.edit
dct cloud identity groups --provider acme.okta.com   # read-only
dct cloud connection access grant warehouse --who revenue-ops --role editor

role edit replaces the name and the whole entitlement list. Identity groups are read-only because the identity provider owns their membership. The "everyone in the org" default on a connection is set on the connection's page, not here.

Audit log¶

dct cloud audit list --actor admin@acme.com --project analytics
dct cloud audit export --format csv --since 2026-10-01T00:00:00Z > audit.csv

audit list filters by --since (ISO 8601), --actor, --action, and --project, and pages with --page and --limit. audit export follows every page and writes one JSON array or one CSV with the columns id, created_at, actor, action, project, and summary. Adding someone to a team or removing them is in the trail too, since it changes who holds every grant the team holds.

Scripting examples¶

Onboard a team to a folder:

dct cloud team create "Revenue Ops"
for email in sam@acme.com riley@acme.com; do
  dct cloud team add revenue-ops --member "$email"
done
dct cloud access grant --project analytics --path finance/ \
  --who revenue-ops --role viewer
dct cloud access check --project analytics --who sam@acme.com \
  --path finance/revenue && echo "Sam can open finance/revenue"

Fail a CI job when a public board appears:

test "$(dct cloud public list --json | jq '.grants | length')" -eq 0

Export last week's audit log:

dct cloud audit export --format json \
  --since "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" > last-week.json

On macOS, use date -u -v-7d +%Y-%m-%dT%H:%M:%SZ.