Docs / Guides by role / Administrator
Guide by role For administrators

Administrator

You hold every permission the other three roles have, plus the two things none of them can do: manage people, and manage what the application connects to. A real deployment gives this role to as few people as possible, because it is the one role that can both ask a question and answer it.

What you decide

  • Everything the use case team, the source owner and the data hub can — admin holds every permission without being named for each one.
  • Add, change the role of, and remove people, on Users.
  • Act as another person, where that is allowed.
  • Connections — what the build runs against, and the credentials for Databricks, ServiceNow and the trackers.
  • Issue and revoke service tokens, from the shell.

Where you work

  • Users (/governance/users) — the role strip, the people table, Add somebody
  • Connections — one row per integration, each opening a sheet to configure it
  • a shell on the box — for the first administrator, and for every service token

Step by step

1. Add somebody. Fill in Add somebody on Users: Name, Email, Role, and — only for a source owner — Any source system or a named one. In open mode the email is optional and they appear with no invite; with accounts on, email is required and a one-time sign-in link is shown once, valid 7 days. Reissue it from the same row — Sign-in link or New sign-in link — which supersedes any password already set. A password must be at least 12 characters.

2. Change a role. The Role select on a person's row changes it at once. It cannot move a source owner to a different system — that is fixed when they are added — so correcting it is Remove, then Add somebody again with the right one.

3. Act as. In open mode, anybody may switch to anybody. Once accounts are required — site, link or site+link — only an administrator may. Under Entra, nobody can: the role there is an assertion the directory made, and a switcher would be a costume over SSO.

4. Connections. Open a row to see what it needs — a hostname, a token, a schema — and Save it. For a warehouse, Save and build into it points every future build, promotion and drift check there; nothing already built moves. A connection marked mock-up is written to the vendor's published shape and has never run against a live tenant.

5. Service tokens, from the shell on the machine that runs the factory, never from a page:

python -m dpf token create NAME --note "who holds it"
python -m dpf token revoke NAME

A token is shown once and kept only as its hash.

6. The first administrator, or the way back in when every administrator is locked out:

python -m dpf user add EMAIL --name "Name" --role admin
python -m dpf user invite EMAIL

add creates the row and prints a one-time sign-in link; invite prints a fresh one for somebody already added.

Warning

The control to remove the workspace's last administrator does not appear — not even for you. If every administrator is locked out of signing in, the shell commands above are the way back.

What the record keeps about you

Every person you add, every role you change, every link you reissue, and every connection you save — each an event with your name and when. Issuing or revoking a token is on the record too; reading with one is not, because a read is never a decision. Switching Act as is the one exception: it is not written to the log at all.

Documentation for version 0.2.0 Reviewed 2026-10-19 Covers dpf/domain/rbac.py, templates/users.html, templates/connections.html, templates/account.html, dpf/cli.py, dpf/web/accounts.py, dpf/tokens.py