What you are building

Accounts for the people who will use AccessFlow, with each one able to do what their job needs and no more. That means three separate decisions, and it helps to keep them separate in your head: what a person may do in the product (their role), which databases they may touch (a grant on each datasource), and for how long (an expiry, or a request that grants itself temporarily).

What is the difference between a role and a grant?

A role decides which parts of AccessFlow a person can use — whether they can submit writes, review other people's queries, or open admin pages. A grant decides which datasource they can query and with what capabilities. Neither implies the other: an analyst with no grants can reach no data, and a grant on its own does not let anyone review.

1. Create the accounts

Sidebar → Security & Access → Users. The control at the top right is a split button with two different paths behind it.

Invite via email — the main half of the button. Opens Invite a teammate: Email, an optional Display name, and a Role. Send invitation emails them a link they use to set their own password. This is the path you want on a real deployment.
Create with password — behind the small arrow. Opens Invite user, which asks for an Initial password alongside the same fields and creates the account immediately. Despite its Send invite button, this path sends no mail at all.

Invite via email needs system SMTP first. Without it the action fails with 422 SYSTEM_SMTP_NOT_CONFIGURED_FOR_INVITE before it creates anything. Set email up with the notifications guide, or use the password path meanwhile.

Sent invitations appear in a Pending invitations table below the user list, where you can resend or revoke one. Links expire after seven days by default (ACCESSFLOW_SECURITY_INVITATION_TTL), and they are built from ACCESSFLOW_PUBLIC_BASE_URL — if that is wrong, your invitees get a link pointing somewhere they cannot reach.

The admin users page with the create-user form open, showing the email, initial password, display name and role fields. — Sidebar → *Security & Access* → **Users**, with the create-with-password form open.

Searching does not span pages. The search box and the role and provider filters narrow the page you are looking at, twenty users at a time — they are not a server-side search. On a large directory, page to the user rather than expecting the box to find them.

2. Pick the right role

Five roles ship with AccessFlow. They are built in: you cannot edit or delete them, and each is a superset of the one above it apart from Auditor, which is a different shape entirely.

Role	What it can do	Give it to
Read-only	Submit SELECT queries, and nothing else.	People who only ever read, and contractors.
Analyst	Read-only, plus INSERT, UPDATE and DELETE. No schema changes.	The default for engineers and analysts. Most of your users.
Reviewer	Everything an analyst can do, plus seeing every query in the organization and deciding them — along with access requests, API calls, deployments, erasure requests and recertification items.	Team leads and data owners. Note it carries no admin or configuration access.
Auditor	Compliance reports, recertification evidence, access-usage reports and the break-glass log. Cannot submit queries at all, which is why signing in as one lands on the compliance dashboard rather than a dashboard with an editor.	Compliance and internal audit.
Admin	Everything, including every permission added in future releases.	As few people as the job allows — see the warning below.

Admin is not just "more access". It carries the review-override permission, which bypasses the approver lists on review plans by design. Any scoping you configure elsewhere — including on deployment pipelines — is scoping over non-admins. Grant it deliberately.

If none of the five fits, build your own: Roles under the admin section creates an organization-scoped role from the permission catalog. It needs a name and at least one permission. Custom role names work as approver rules on review plans just as the built-in ones do.

3. Grant access to a datasource

Open the datasource → Permissions tab → Grant access. Grants go to an individual or to a group, and carry rather more than an on/off switch:

Can read, Can write, Can run DDL — at least one is required.
Row limit override — a tighter cap than the datasource's default for this person.
Allowed schemas and Allowed tables — leave empty for everything, or narrow it. Submitting a query that touches anything outside the list is refused.
Restricted columns — masked in this person's results.
Expires at — optional, and the single most useful field on the form. Access that removes itself is access nobody has to remember to remove.

Where someone has both a direct grant and one through a group, the effective result is the most permissive combination of the two.

Break-glass is granted here too, and it is not an ordinary capability. Can break-glass lets its holder bypass review entirely and execute immediately. It is compensated rather than prevented: every admin is notified, the action is prominently audited, and an admin who is not the submitter has to acknowledge it afterwards. It does not stand alone — the user still needs the matching read, write or DDL capability. Set an expiry on it.

4. Use groups once individual grants stop scaling

Sidebar → User groups. A group is a named set of people that can hold datasource and API-connector grants of its own, so joining the group is what confers access and leaving it is what removes it.

Membership can be manual, or synced from your identity provider — the members table shows each person's source as Manual, IdP or SCIM. If you are heading towards IdP-managed groups, connect single sign-on first and let the group memberships arrive with the users.

5. Let people ask, instead of granting up front

Standing access is the thing you are trying to avoid. Any signed-in user can open Request access and ask for a scoped, time-boxed grant: a datasource, the capabilities they need, optionally specific schemas and tables, a duration, and a justification. Durations run from one hour to seven days.

Requests land in the Access requests queue for anyone who can review them. Approving materialises a real grant that expires by itself; a background job revokes it when the clock runs out. Rejecting requires a comment.

Pre-approve queries under this grant is worth understanding before someone ticks it. It lets queries covered by the grant's capability and table scope skip human review for as long as the grant is active — useful for a bounded on-call window, and a much bigger decision than the checkbox looks. High-risk queries and routing policies still apply.

Duration bounds are configurable with ACCESSFLOW_ACCESS_MIN_DURATION (15 minutes by default) and ACCESSFLOW_ACCESS_MAX_DURATION (30 days).

6. When someone leaves

On the users page, open the row's menu and choose Deactivate. Three things happen: the account is disabled, every one of its sessions is signed out immediately, and every active just-in-time grant it holds is revoked.

Standing grants are not revoked. Deactivation removes the temporary grants somebody requested, not the permanent rows an admin created on a datasource's Permissions tab. Those survive the account being disabled, and would apply again if it were ever reactivated. Remove them explicitly.

You cannot deactivate yourself — the API refuses it, so an organization can never lock out its last admin by accident.

If your identity provider is the source of truth, this should not be a manual step at all: SCIM deprovisioning raises the same event and takes the same actions. See SCIM provisioning.

Full reference for roles, the permission matrix, groups and grants: Users & roles.