Workspace

Workspace is organization-level administration. Open it from the header link Workspace (default: Members).

Workspace side rail

The left Workspace rail lists Members, Invitations, User groups, API tokens, Custom fields, and Activity. On desktop you can collapse it to an icon-only mini-rail; the organization avatar or initial stays visible in the header. Hover or focus an icon to read its label in a tooltip. Collapse state is saved per browser and is independent from project or user rails.

Members (/workspace/members)

The screen matches the Invitations visual system: a mono workspace / members breadcrumb, page title, role-explainer description, and an Invite members action that opens the invite dialog in place (no export control).

Owners and admins can:

• Search members by name or email from the shared filter bar’s search slot (server-side, case-insensitive, debounced)
• Add a Role filter from Add filter — a multi-select chip over Owner, Admin, Member, and Viewer. Selected roles are OR-ed (role=admin,owner); search and the role chip combine with AND logic server-side; a N of N count shows how many rows match. Filter state lives in the URL and any change resets to page 1
• Review table columns: Member (profile photo when uploaded, otherwise initials avatar; display name from profile or email; full email; YOU badge on your row), Role (chip), In organization since (absolute date plus relative subline), Actions
• Change a member’s role via the inline per-row control (PATCH /api/orgs/:orgUlid/members/:userUlid) — you cannot promote someone to owner from this screen
• Remove a member via the trash icon (DELETE on the member) with a confirmation prompt

On a narrow (phone-width) screen the table becomes a card list: each member presents as its own card, showing the same role chip and join date, with the role-change control and remove action still available on the card. Every search, filter, and action you have on a wider screen is still there — only the layout changes. At tablet width and above the list is the table described above.

You cannot remove or demote yourself, and the sole owner cannot be removed or demoted (the API returns 409 last_owner if violated). Promoting a viewer to a paid role is refused with 409 seat_limit_exceeded once the organization is at its seat limit; a viewer never consumes a seat, and demoting a member frees one for the next invite or promotion.

Invitations (/workspace/invitations)

The screen matches the product mock: a mono workspace / invitations breadcrumb (no separate page title), a New invitation action that opens a modal (rather than an inline form on the page), and an Invitation history section. The history’s shared filter bar offers a search input (invitee email, server-side and debounced) plus Status and Role chips from Add filter — each a multi-select writing comma-separated params (status=pending,expired). Values OR within a chip and AND across the search and both chips; any change resets to page 1. The history filters do not affect the invite modal.

The New invitation modal has two tabs, Single and Bulk, each with its own Access checkbox:

• Single sends one invitation: enter an invitee email and role (admin, member, or viewer — not owner) and select Invite. The invitee receives an email with a link /invite/:token.
• Bulk sends up to 50 invitations at once under one shared role: paste addresses separated by newlines, commas, or semicolons, and a counter under the field reports how many distinct addresses will actually be submitted (blank lines and case-different repeats don’t count twice). If every address is created, the modal closes; if any address is refused, the modal stays open, lists each refused address next to its own reason (already invited, already a member, or not a valid address), and keeps only the refused addresses in the field so a corrected resubmission can’t duplicate an invitation that was already created. A refusal that applies to the whole list (for example, hitting your organization’s seat limit) is stated once and is never attributed to a single address.
• Access: check it to grant the invitee — or, on the Bulk tab, every address in the list — access to every private project once they accept the invitation; the grant replays at acceptance, it is not immediate. For the owner and admin roles the checkbox is shown disabled, with a note explaining that role already reaches every project, so checking it would grant nothing.

Owners and admins can also:

1. Review history columns: Email · status (row mail icon, plain status text, role chip), Invited by (initials avatar, display name, and visible inviter email), Sent and Expires (absolute date plus relative subline where applicable).
2. For pending rows, use icon actions to Resend (POST /api/orgs/:orgUlid/invitations/:invitationUlid/resend, rotates the one-time token and sends mail again) or Revoke (DELETE on the invitation).

A pending row whose email could not be delivered shows a caution indicator next to its status: Undeliverable — invite a different address means the recipient’s mail provider permanently rejected the address (a bounce or a spam report) — inviting a different address is the only way forward. Delivery failed — you can resend it means delivery was retried and did not succeed for another reason — resending may work. Either way, the invitation itself stays Pending; it is not automatically revoked. The indicator can take a short time to appear after you send or resend the invite (delivery happens after the request completes) and survives a page reload.

On a narrow (phone-width) screen the invitation history becomes a card list: each invitation presents as its own card, showing the same email, status, role, inviter, sent, and expires values, with resend/revoke still available on pending cards. At tablet width and above the list is the table described above.

Status labels are short (Pending, Expired, etc.). Inviter avatars use initials from email (profile photos are not loaded in v1).

Limits: one pending invite per email per org; up to 50 pending invitations per organization; invitations expire after seven days.

User groups (/workspace/groups)

Groups let owners and admins organize members into collections they can manage together — a name, an optional description, and a member roster. Group-based project access does not exist yet: the list’s PROJECTS column and the detail’s Projects tab both read as inert, showing what is coming without implying it already works.

The list matches the workspace visual system: a TITLE column showing the group’s name with its description on a subordinate second line (omitted entirely for a description-less group), USERS and PROJECTS counts, and a New group header action. A single free-text search box (no filter chips — a group has no categorical field to chip yet) searches both the name and the description, server-side, and travels in the URL.

Owners and admins can:

1. Create a group from New group: a name (required, unique in the organization), an optional description, and an optional members field — a searchable multiselect showing each organization member’s avatar, letting you seed the group’s initial roster in the same step instead of adding members one by one afterward. This field only appears on create; editing a group’s name or description later does not offer it — use the detail screen’s Add member/Remove from group actions to manage membership after creation.
2. Rename a group or edit its description from the row menu’s Rename action — one dialog, the same form used to create.
3. Delete a group from the row menu’s Delete action. A group with members is deleted along with its membership rows in one step; there is no requirement to empty it first.
4. Open a group to reach its detail screen at /workspace/groups/{groupUlid}, addressed by the group’s ULID (not a slug) so renaming never breaks a bookmarked link.

The detail screen shows the group’s name and description with the same rename/delete actions, and two tabs:

• Members — the group’s roster: avatar, name and email, role chip, position title, and a per-row Remove from group action with a confirmation naming the person. An Add member action offers only organization members not already in the group.
• Projects — a finished-looking, inert placeholder for the group-based project access this release does not yet ship.

On a narrow (phone-width) screen both the list and the Members register become card lists, with every action persistently visible (never hover-only). At tablet width the row actions consolidate into a single menu; at desktop and above the full row is visible.

Members with role member or viewer see a permission message in place of the register on both screens; the rail entry itself stays visible to every member regardless of role.

API tokens (/workspace/api-tokens)

The screen matches the Invitations and Members visual system: a mono workspace / api tokens breadcrumb (current segment in accent), page title, and description.

Owners and admins can:

1. Create a token from the New token card: Name input (bg-input styling) and an accent Create token button with a key icon. There is no organization picker — the token is always created for the organization that has the focus.
2. Copy the clear-text secret from the amber one-time reveal panel immediately after create (dismiss with Close); the secret is not shown again.
3. Search tokens by name and narrow them with the Last used chip (Used / Never) from the shared filter bar. The list is paginated; filter state lives in the URL and any change resets to page 1. The request is always scoped to the active organization server-side.
4. Review active tokens in a table with columns Name, Created (absolute date plus relative subline), Last used (dual-line date or Never when unused), and Actions.
5. Revoke a token with the trash icon (DELETE /api/v1/me/api-tokens/:ulid) after a confirmation prompt.

On a narrow (phone-width) screen the token list becomes a card list: each token presents as its own card, showing the same created and last-used values, with revoke still available. At tablet width and above the list is the table described above.

There is no per-row organization column (the screen is scoped to the active organization). Distinct loading, empty, error, and empty-filtered states are shown for the token list.

Custom fields (/workspace/custom-fields)

Owners and admins define organization-wide metadata fields (system and custom) and which projects each field applies to. See the dedicated guide: Custom fields (Workspace).

Attachments (/workspace/attachments)

Every member can monitor storage usage and browse every file the organization has uploaded, across all attachment surfaces. Owners and admins can additionally select files and bulk-delete them. See the dedicated guide: Attachments (Workspace).

Activity (/workspace/activity)

Owners and admins can review an append-only feed of domain changes (projects, cases, members, invitations, API tokens, and more). See Workspace activity in the product docs site for details.