Run your first governed query.
Last updated
What you are building
A query that a person writes, an AI scores, a human approves, and AccessFlow then runs against a real database — with the whole sequence recorded. It is the shape every other part of the product is built on, so it is worth doing once end to end before you configure anything else.
Allow about half an hour. You need AccessFlow running (the install chapter covers Docker Compose, Helm and running from source) and a database you are willing to point it at — a scratch one is ideal.
How does a query get approved in AccessFlow?
A user picks a datasource and writes SQL. AccessFlow parses it, checks it against that user's permissions, optionally has an AI model score its risk, and then holds it for whoever the datasource's review plan names as an approver. Once approved it runs through the proxy, under masking, row limits and any row-level rules that apply.
1. First run
Open AccessFlow in a browser. While no admin exists, every route redirects to
/setup and you get a two-step form.
- Create the first admin. Organization name, Email, Password (8–128 characters) and its confirmation are required; Display name is optional.
- Configure system SMTP — or do not. The second step is explicitly optional and offers Skip for now beside Save & finish. Skipping is fine for now; you can set it up later with the notifications guide.
Either button finishes setup and drops you at /queries. Sign in from then
on at the normal login screen, which lands you on your dashboard.
ACCESSFLOW_BOOTSTRAP_ENABLED=true and declare the organization, the first
admin and much else in configuration, reconciled on every start. See
first-time setup.
2. Connect a database
Sidebar → Datasources → the button that adds one. The wizard has four steps: Database type, Connection details, Connection test, Configuration.
PostgreSQL, MySQL, MariaDB, Oracle and SQL Server connect straight away. Everything else — MongoDB, Redis, Snowflake, BigQuery and the rest — needs its connector installed first, which is a one-click job from the catalog. Either way, use credentials scoped to what you actually want reachable: AccessFlow governs who may ask, but the database account still bounds what is possible.
Run the connection test before continuing. A datasource that is not active does not appear in the editor at all, so a failure here is worth fixing now rather than debugging later as a missing dropdown entry.
Add your first datasource covers the wizard field by field, plus the table allow-list, masking and row-level security you will want before this touches anything real.
3. Decide who approves
A review plan is the policy that says what has to happen to a query before it runs. Sidebar → Security & Access → Review plans → Add review plan.
Almost everything is pre-filled sensibly — AI review on, human approval on, Minimum approvals 1, Approval timeout (hours) 24. In practice you need to supply two things:
- A name.
- One approver row. Leave Role on
Reviewerand Stage on1. A row needs either a role or a specific user; a role is easier to live with.
Then attach it: open the datasource's settings, Configuration tab, Review plan. A plan is attached to a datasource, not to a person.
4. Create the person who will submit
Sidebar → Security & Access → Users. The control at the top right is a split button: its main half is Invite via email, which needs system SMTP. If you skipped SMTP in step 1, use the small arrow beside it and pick Create with password instead — that path creates the account directly and sends nothing. Invite your team covers both paths, and the roles, in full.
Leave the role on Analyst. An analyst may submit reads and writes; it is the ordinary shape of a person who queries production.
A role does not grant access to any particular database, though. Open the datasource → Permissions tab → Grant access, choose the new user, and leave Can read on. You can also cap rows, restrict the grant to named schemas and tables, mask specific columns, and set an expiry — all optional, and all worth revisiting once the basics work.
5. Submit a query
Sign in as the analyst — a private window keeps your admin session alive — and open the SQL editor. Pick the datasource and write something harmless:
SELECT count(*) FROM orders;
Fill in Justification. Nothing rejects an empty one, but it is the first thing a reviewer reads and an empty box makes their decision harder than it needs to be.
Then Submit for review. The editor navigates to the query's own page, where you can watch it move through its statuses.
A submitted query passes through Pending AI to Pending review. If you have not configured an AI provider yet, it simply moves on without a risk verdict — analysis is optional, and a failed analysis sends the query to a human rather than through.
6. Approve it, and watch it run
Back on your admin account, open the Review queue. The query is there with its SQL, its submitter, its justification and its AI verdict if there is one. Approve it. Rejecting is also available, and requires a comment — a rejection without a reason is not much use to the person who has to fix it.
The status moves to Approved and then Executed, and the results appear on the query's page for the submitter. That is the whole loop.
403 to anyone who tries it directly,
admins included.
Every query the analyst submits is listed under Query history, with the statuses you just watched: Pending AI, Pending review, Approved, Executed — plus Rejected, Timed out, Failed and Cancelled for the paths you did not take this time.
Where to go next
You now have a working pipeline. The usual next steps, roughly in order of urgency:
- Add a datasource — limit which tables can be queried at all, mask sensitive columns, and add row-level rules. Do this before you point AccessFlow at anything that matters.
- Send notifications — so reviewers find out a query is waiting without watching a page.
- Invite your team — roles, groups, and access that expires by itself.
- Turn on AI analysis — give reviewers a risk level and a reason before they decide.
- Routing policies — once the queue is busy enough that reviewing every read by hand stops being sensible.
- End-user workflows — the same loop written for the people who will live in it: submitting, tracking, scheduling and reviewing.