Team Members

Invite collaborators to a tenant or project, assign roles, and manage who can do what. Team members are the people on your team — engineers, editors, agency partners — who sign in to the admin app or use the CLI. They are not the end-users of your storefront; for end-user accounts see Customer Authentication.

Overview

A tenant is the top-level workspace that owns one or more projects. Every team member is invited to a tenant and granted a role; that role determines what they can see and change inside each project under the tenant.

Role	Scope	Can do
Tenant Owner	All projects in the tenant	Everything — billing, member management, project creation, content, configuration. Granted automatically to the person who creates the tenant.
Project Admin	Per project	Manage members of this project, edit configuration (models, operations, hooks, schedules, design tokens), edit and publish all content.
Project Editor	Per project	Create, edit, and publish content within this project. Cannot edit configuration or manage members.
Project Viewer	Per project	Read-only access to records and configuration. Cannot publish or create.

A single user can hold different roles in different projects under the same tenant — invite an agency partner as Editor on one project and Viewer on another.

Who can see whom

The Members list is scoped to the people whose workspace you share. This boundary is enforced at the database row level — not merely hidden in the UI — so it holds identically across the admin app, the API, and the CLI.

Your role	Who appears in your Members list
Tenant Owner	Every member of the tenant, across all of its projects.
Project Admin / Editor / Viewer	The members of the projects you belong to. Any role in a project — Admin, Editor, or Viewer — sees that project’s roster.
Foir platform staff	Everyone, for support and operations. Foir operators never appear in your Members list, and entering a tenant is an audit marker, not a visibility gate.

The same row-level boundary governs reading and editing a member record: you can view only a member you can see, and a member’s profile (name, avatar, status) can be edited only by that person or by Foir platform staff. Changing a member’s role or removing them is a separate Tenant Owner / Project Admin action — see Managing existing members below. Add new teammates with Invite member rather than creating accounts directly.

Field-level access on record data follows the same model: each field’s read/write policy names the principals allowed to touch it (public, self, scoped, service, admin), enforced on every write path. See Field-Level Access Control.

In the admin

Inviting a member

Navigate to Workspace → Members.
Click Invite member.
Enter their email and pick a role (Tenant Owner / Project Admin / Project Editor / Project Viewer).
Click Send invite. The invitee receives an email with an accept link.

Invitations expire after seven days. Pending invites appear in the Members list with a Pending badge — you can resend, copy the accept link, or revoke from there.

Managing existing members

From Workspace → Members:

Change a role — click the role dropdown next to a member. The new role applies immediately.
Revoke access — click Remove. The member loses access on the next request; their existing API tokens are not invalidated (they’re personal-use tokens issued at signin, not portable).
Transfer ownership — Tenant Owners can promote another member to Tenant Owner. There can be more than one owner; demote yourself only after promoting someone else.

Reviewing invitations

Pending invites are listed under Workspace → Members → Pending. Each shows:

Email
Role
Sent date
Status (Pending, Expired, Revoked, Accepted)

Use Resend to re-send the email (useful if it landed in spam) or Revoke to cancel an outstanding invitation.

Where team members are managed

Team members, invitations, and role changes are managed entirely in the admin app under Workspace → Members, as described above. There is no public GraphQL API for inviting or removing team members or changing their roles — these are admin-app actions.

Note that this is distinct from customer accounts: your storefront’s end-users live in a separate system that does have a programmatic surface. See Customer Authentication for that.

Roles in practice

Some rules of thumb when deciding which role to grant:

Outside agencies / freelancers doing content work: Project Editor on the project they’re working on. Drop them to Viewer or remove when the engagement ends.
Internal developers who edit models and operations: Project Admin on staging projects, Project Editor on production projects (so they push schema changes via foir push from CI, not by hand).
Read-only stakeholders (PMs, analysts): Project Viewer. They can browse content and reports without risk of accidental edits.
Owners / founders: Tenant Owner. Keep this list short — Tenant Owners can change billing and add new owners.

Limits

One pending invitation per email address per tenant. Revoke and re-invite to change role.
Invitation links are single-use and expire after seven days. After expiry, send a new one.
A tenant must always have at least one Tenant Owner. The platform refuses to demote or remove the last owner.

Customer Authentication — for your storefront’s end-users, which is a separate system.
API Keys — programmatic credentials, distinct from member sessions.
Billing & Usage — Tenant-level concern, managed by Tenant Owners.