Plural
Docs

People and organizations

A project is the workspace for your Environments, Tasks, Agents, Jobs, and results. An organization groups projects and collaborators under a shared account. Organization membership and project access answer different questions: who belongs to the organization, and what work can they access?

Invite someone to a project

  1. Select the intended account and project in the workspace switcher.
  2. Open People.
  3. Choose + Invite, enter the person's email, and select a starting role.
  4. Choose Send invite. Check the pending invitation and the project's access list.

Project admins can manage invitations. The recipient should open the invitation and sign in with the email address it was sent to. A link opened under another email will not be accepted.

For an existing user, the current service can grant project access when the invitation is created, before the invitation is accepted. A pending invitation therefore does not always mean the person has no access. Check the actual access list when confirming or removing access.

Choose a project role

  • Admin: manage project settings, access, and keys, as well as project work.
  • Member: create and modify project resources and run work where the project's policies permit it.
  • Viewer: inspect project resources and results without permission to author or run work.

A reviewer who must submit scores needs write permission; viewer access is for inspection. Do not assign admin solely because someone needs to review a Trial.

The People list lets admins change roles and remove grants. The last required admin cannot be removed through an operation that would leave the project without administration. Where access is inherited from organization ownership or a team, inspect that source too.

Invite someone to an organization

  1. Open Organizations and select the organization.
  2. Open Members.
  3. Choose + Invite, enter the email, select the organization role, and send the invitation.
  4. Confirm the person's membership after acceptance, then grant access to the projects they need.

Organization owners and admins manage membership. Owners additionally control owner-role changes. The last owner cannot be removed or demoted in a way that leaves the organization ownerless. Regular members collaborate through their project and team grants.

Organization owners and admins have administrative access to organization-owned projects. Ordinary organization membership does not automatically grant access to every project. This distinction matters when choosing an organization role: use project grants for a collaborator who only needs one workspace.

Work with teams

Open the organization's Teams section to organize members. Project access can be granted to a user or to a team. A team grant applies to its members, so changing team membership can affect project access.

If someone has several matching grants, their effective project role is the strongest applicable role. Removing one direct grant may not remove access inherited from a team or organization administration. Check all applicable sources when troubleshooting access.

Manage invitations

Pending invitations appear in the relevant People or Members list. Revoke an invitation that should no longer be used. If an invitation expires, send a fresh invitation through the same workflow. Use the newest link and the matching signed-in email.

Revoking an invitation and removing an existing access grant are separate actions. For a person who already has access, inspect and remove the relevant grant or membership as appropriate.

Use keys for scripts

A project-scoped API key is limited to its project. Use it for a script working on one project; it cannot enumerate unrelated projects or organization members. An account credential is intended for operations within the account's permitted scope, with explicit project context where required.

Keep credentials out of source files, Agent instructions, and Task metadata. Human membership, API-key scope, and execution policy all matter; possession of a project identifier is not authorization.

If a collaborator cannot see the work

Confirm the selected account and project, the email used to accept the invitation, and the actual user or team grant. Check whether the person has only organization membership. If a read works but a mutation fails, inspect their effective role and project policy before issuing broader credentials.