The organization page and what it cannot do

The organization page is one screen: the workspace it names, and the list of people in it. What an organization owns, which role is allowed to do what, and why the data boundary holds in the query rather than in the page are all covered by how organizations work. This page is about the surface at /app/organization: what it shows, who can open it, and the things it looks like it should do and does not.

What it shows

The workspace name and its slug, then a section headed Team with one line per member.

What each line of the Team list contains

Shown	Read from
Email address	The user record, joined to the membership
Role	The membership record, which is the organization role and not the account role used by the administration console

Nothing else is on the line. No display name, no date of joining, no last-seen time, no pending invitation, no indication of who added anyone.

It is a list, not a console

What this page can and cannot change

Action	Available here	Note
Read the member list with addresses	Owner and admin only	Every other role sees its own role and a count of the active members
Rename the workspace or change its slug	No	No page on this site updates an organization record after it is created
Invite somebody	No	There is no invitation flow anywhere on the site, and no mailer to carry one
Change a member's role	No	The only role this product ever writes is the owner role given at workspace creation
Remove or deactivate a member	No	The membership record carries an active flag that no page sets

So the page is a statement of fact about the database, and every way of changing that fact is outside the product.

Anybody can open it, but not everybody sees the same thing

Role required to open it

Any member

the setup checklist links every user here, so the route is not gated; what narrows by role is the data, not the door

Links to it in the workspace navigation

None

the sidebar and the mobile menu do not list it; the only link is the Review organization step on the setup page

Where sign-in returns you

This page

the guard is handed this route, so a signed-out visitor who asked for it lands back on it

Both of those rows were defects until 2026-09-12, and they are recorded here because the fix explains the shape of the page.

Every member's email address used to be visible to every other member, including a viewer who can change nothing in the workspace and who is often an external accountant or bookkeeper. The addresses are now not selected from the database at all for a caller who may not see them, rather than being fetched and left unrendered, because a field that is fetched and merely not displayed is one careless refactor away from being displayed again.

The page also used to hand the guard no route of its own, so a signed-out visitor who asked for it was returned to the dashboard instead of back here. Every other workspace page named itself, and tests/unit/workspace-page-authorization.test.ts had this one recorded as the single exception. That table now has no exceptions left.

Where the members came from

The only code that creates a membership is the bootstrap that runs when a signed-in account has no active one. It creates an organization named after the account, makes that account its owner, and stops. Nothing else inserts, updates or deletes a membership row.

In normal use, then, this list has exactly one line on it, and that line is you. A second name appearing here means a row was added to the database directly, not through anything on this site.

The empty state promises a check the query does not make

What to read next

Roles, what each one may do, and why a viewer posting directly to the API is refused the same way the interface refuses them: how organizations work. Your own membership in every organization, with its role and its active flag, is part of the personal-data export described in your data and privacy. The organization values that cannot be edited, and the one control that settings really carries, are in workspace settings.