team

surrealctl team manages organisation members: the people who already belong. Invitations that have been sent but not accepted live in invite, and team list deliberately does not fold them in — a pending invitation is not a member.

surrealctl team <COMMAND> [OPTIONS]surrealctl teams <COMMAND> [OPTIONS]

Two verbs here break the house grammar on purpose. remove is not delete, because delete invites the reading that the person is deleted rather than their membership. invite exists because sending one is how a team gains a member and no house verb covers it — and it shares invite create's implementation rather than copying it.

The API has no route for a single member, so get, update and remove fetch the member list and match locally, by id or username, with did-you-mean suggestions when nothing matches.

surrealctl team list

List the members of an organisation.

surrealctl team list [OPTIONS]

This command takes no positional argument. The organisation comes from --org and the precedence chain.

Accepts the list presentation flags and nothing else. Column ids are username, name and role, with user_id and profile_picture under --wide.

surrealctl team list

USERNAME             NAME            ROLE
ana@acme.example     Ana Silva       owner
bo@acme.example      Bo Nakamura     admin
cai@acme.example     Cai Oduya       member

surrealctl team list --json | jq -r '.[] | select(.role != "member") | .username'

surrealctl team get

Show one member.

surrealctl team get [OPTIONS] <MEMBER>

This command has no options of its own.

surrealctl team get bo@acme.example

A username that does not match any member exits 5, and lists the near matches it found.

surrealctl team invite

Invite someone to an organisation.

surrealctl team invite [OPTIONS] --role <ROLE> <EMAIL>

surrealctl team invite dee@acme.example --role member

The answer is the invitation, not a member — the person appears in team list only once they accept. Track it in the meantime with invite list.

Refusals, exit 2, before any request. The address validator is deliberately shallow — an @ with something either side and no internal whitespace — because the API is the authority on deliverability:

`dee.acme.example` is not an email address: it has no `@`.

The role vocabulary is per organisation, so only an empty value is refused locally:

A role cannot be empty. Run `surrealctl org roles` to see the ones this organization defines.

A role the API rejects as invalid is annotated with a pointer to org roles — but only for that class of error, never for a 403 or a rate limit, where the role is not the problem.

surrealctl team update

Change a member's role.

surrealctl team update [OPTIONS] --role <ROLE> <MEMBER>

surrealctl team update cai@acme.example --role admin

surrealctl team remove

End someone's membership of an organisation.

surrealctl team remove [OPTIONS] <MEMBER>

surrealctl team remove cai@acme.example

surrealctl team remove cai@acme.example --force --json

This ends a membership. It does not delete the person's SurrealDB account, and it does not touch anything they created.

Refusals. The confirmation names the person. Declining exits 0. In a non-interactive session without --force or --yes, it exits 2 having sent nothing.

Related pages

• •

  invite commands — pending invitations

• •

  org roles — the roles this organisation defines

• •

  org permissions — what a role lets you do

• •

  Overview — the rest of the reference

• •

  SurrealDB CLI — database users, which are a separate concept from organisation members