Workspaces, roles, and the audit log
A workspace is the unit of visibility. Four roles say what a member may do, staff runs den without seeing inside, and the audit log records who changed what and which version.
2 min read · On this page: Workspaces · Roles · Staff · The audit log
#Workspaces
Every person gets a personal workspace at sign-in. Anyone can create a shared one and becomes its owner. A topic belongs to one workspace; search, the changes feed, export, and share links all stay inside it. The switcher in the sidebar lists the workspaces you belong to and nothing else.
#Roles
| Role | May |
|---|---|
| owner | Everything, including who owns the workspace |
| admin | Manage members and kinds, read the audit log, and every write. May not grant or revoke owner. |
| member | Read and write topics and artifacts |
| viewer | Read only |
Owners and admins add people by the email of their den account and change roles on the Members page. Anyone may leave a workspace; the last owner cannot step down until another owner exists.
#Staff
Some people run den itself: they send invites, manage accounts, review the marketplace, and install den-wide views. That is the staff flag, and it is not a workspace role. Staff sees the list of workspaces and their member counts, and nothing inside a workspace it is not a member of.
When support needs to look inside, a staff member opens a sudo session: one workspace, a required reason, one hour. Read mode shows the workspace as a viewer; user mode shows it as one chosen member sees it, read-only; write mode gives owner powers and audits every request. The session starts and ends as rows in that workspace's audit log, so the members can see it happened and why. A sudo session cannot create tokens, approve connectors, or send invites.
#The audit log
Every change writes one row: who, from which device or connector, what action, which topic and artifact, and for a commit the version written and the version it replaced. Member changes, shares, kind changes, and sudo sessions are rows too. Owners and admins read the log under Audit, filter by action, person, topic, artifact, and date, and open the exact version a row points at. Agents get the same through list_audit.