Skip to main content
The Settings → Team page is the manual membership console for your organization — where you invite people, track pending invitations, assign and change roles, remove members, and watch who changed what. Everything on the page is tenant-owned: members, invitations, and role assignments live in your organization and take effect immediately. Nothing here alters how calls or messages are delivered. This is the console to reach for day to day. If you run an identity provider — Okta, Entra ID, OneLogin — provision members automatically over SCIM instead (SCIM provisioning) and use this page only for the occasional manual adjustment. Looking for routing “teams” that group agents for conversation assignment? That’s a different feature — Teams — and it consumes the membership you manage here.

​
1. Who can use this page

The page is gated to the owner and admin roles. Users with any other role (supervisor, developer, billing, viewer) who open Settings → Team see the Settings hub instead — the Team card simply isn’t available to them. One nuance within that pair: removing a member is owner-only. An admin can invite, resend, revoke, and change roles, but the Remove control only renders for the owner, because the server rejects a removal attempt from anyone else.

​
2. Invite a member

Two invite dialogs sit at the top of the page:
  • Invite member — one email address plus one role. Use it when adding a single person.
  • Bulk invite members — paste a list of email addresses and send them all the same role in one pass. Use it when onboarding a whole intake or a new department. Each address gets its own invitation; a malformed entry is reported so you can fix and resubmit.
The invitee receives an email with an accept link. Once they accept, they move from the pending-invitations list into the members table with the role you assigned. One behavior to know about: if you invite someone whose email already has an Orbit account — for example they previously signed up for a different organization — the invite still succeeds; they receive the email and join your organization when they accept. The one email you cannot invite is the current owner’s own address, and the owner role itself is never assignable through the dialog — ownership transfers, it isn’t invited. Assign the narrowest role the person needs. The matrix below (Section 5) shows exactly what each role can touch before you send the invitation.

​
3. Pending invitations

The Pending invitations card lists every invitation that hasn’t been accepted yet — email address, assigned role, who invited them, and how long ago. From here you can:
  • Resend — re-send the invitation email for one invite. To avoid spamming a mailbox, the button is disabled for a few seconds after a resend.
  • Resend all / Resend selected — when several invites are pending, tick specific rows or press the bulk action to re-send everything. Each send is attempted independently, so one bad address doesn’t stop the batch.
  • Cancel — revoke the invitation. The accept link in the original email stops working immediately, and the person can be re-invited later. Cancel asks for confirmation first.
The card disappears entirely when nothing is pending, so an empty page state just means no outstanding invitations. If the list fails to load, a retry control appears in place of the list.

​
4. Members table

The members table lists everyone currently in the organization — your own account always appears at the top, and the rest are merged from the live roster and sorted with a filter that matches on name, email, or role (useful when you’re hunting one person in a long roster). Each row shows:
  • Name and email — the member’s identity.
  • Role pill — their current role, color-coded the same way as the role matrix reads.
  • Last active — when they last used the dashboard.
  • Change role — pick a new role from the menu; the change takes effect immediately.
  • Remove — owner-only, as noted in Section 1. Removing a member revokes their access to the organization; their historical audit-log entries remain.
Two of the page’s behaviors are worth understanding rather than working around:
  • You always appear in the table. If the roster fetch doesn’t include your own account, the page synthesizes a row for you — shown as pending until the server confirms your real role — so the member count never reads one short. Duplicate entries are deduplicated by user id or by email, matched case-insensitively.
  • While your own account is in that pending state, the table deliberately keeps role-change and remove actions cautious: it assumes only the minimal set until the server confirms what you actually hold.

​
5. Role permissions matrix

The Role Permissions card is the reference you read before assigning a role. It renders as a matrix — one resource per row (messages, contacts, campaigns, agents, numbers, webhooks, billing, settings, and the audit log), one assignable role per column — with each cell showing one of four access levels:
  • Full access — create, edit, and delete on that resource.
  • Read & write — create and edit owned resources, no destructive administration.
  • Read only — view lists and detail pages, no changes.
  • No access — the resource is hidden and its requests are refused.
Assigning a member the admin role, for example, gives them full access across the mailbox-side resources but no billing access; a billing member manages invoices and payments without seeing anything else of the platform. The card alternates between this matrix and a row of per-role summary cards — the toggle at the top of the card remembers your choice across visits. The owner role appears only in the summary-card view: it isn’t assignable, so the matrix correctly omits it as a column.

​
6. Activity log

The Activity card shows the ten most recent membership actions in the organization — invitations sent and accepted, role changes, removals — with the acting user, the target member, and the timestamp. Timestamps follow the viewer’s own timezone so the feed lines up with the audit-log table on the Settings hub. This card is a convenience view of the most recent few entries. For the complete, exportable record — the one auditors ask for — use the full audit log.

​
7. Relation to routing teams

Membership here and the teams you create for conversation routing are two separate concepts that connect in one direction: a routing team’s roster can only contain users who already belong to your organization. The flow is:
  1. Invite the person here, on Settings → Team, and let them accept.
  2. Then add their user account to a routing team from Voice → Teams.
The routing-teams feature — create-team, roster management, and the assign_team routing action that load-balances inbound conversations across the team — is documented in Teams. Roles you assign here still control what those team members can do across the dashboard; routing teams do not grant or widen any permissions.

​
8. SCIM as the automated alternative

When your organization runs on an identity provider, manual invitations don’t scale. Turn on SCIM and membership follows your directory: assign someone to the Orbit application in the IdP and they appear here; unassign them and access is revoked. You map IdP groups onto Orbit roles, so the role-permissions matrix still applies — it’s just enforced at sync time rather than by an invite dialog. See SCIM provisioning for the Okta, Microsoft Entra ID, and OneLogin walkthroughs. Nothing forces a choice — plenty of organizations provision over SCIM and still use this page for one-off contractors or exceptions.