Skip to main content

​
Summary

Team management is where owners and admins control who can access the organization and what operational responsibility those teammates should have. The current app shows dedicated teammate list views and add-teammate flows, which means this page should focus on operational team setup rather than abstract permission theory alone.

​
Who this is for

  • Owners and admins
  • Operations leads managing workspace access
  • Internal teammates helping customers set up initial account access

​
Where to find it in the app

  • Team
  • Settings → Team

​
What the current app suggests matters

The current team surfaces show fields like:
  • teammate email
  • role
  • organization
  • locked status
  • created date
That suggests the docs should eventually explain:
  • how to add a teammate
  • how to understand whether an account is locked
  • how roles affect access and workflow responsibility

​
The practical workflow

​
Add teammates

The app includes an explicit Add Teammate flow rather than treating team membership as a side effect of sign-up. That means team access should be managed intentionally. The current create flow suggests admins define:
  • email and password
  • name
  • role
  • organization

​
Review existing teammates

The team list is not just a directory. It is the quickest place to confirm:
  • whether the person exists in the organization
  • which role they have
  • whether the account is locked
  • when the account was created

​
Edit teammate details

The detail flow suggests owners or admins can revisit teammate records to adjust role and organization-related details later.

​
When to start here

Start with Team management when the question is:
  • “Does this person actually belong to this organization?”
  • “Why can’t they access what I can?”
  • “Is this teammate locked?”
  • “Who should own this setup or review responsibility?”
Do not start here when the problem is really a user’s own profile or password-management issue.

​
Good access hygiene

  • add teammates deliberately instead of sharing credentials
  • assign roles based on responsibility, not urgency
  • check locked state before assuming a permission bug
  • keep a short list of who should own sensitive settings and approval actions

​
Common mistakes

  • assuming account creation alone gives the right access
  • using owner/admin access more broadly than needed
  • treating “locked” like a minor UI detail
  • debugging the wrong surface when the real issue is self-service account access

​
Success checklist

  • The right teammates have been added.
  • Roles are assigned intentionally.
  • Locked or inaccessible accounts can be recognized quickly.
  • The team understands which settings require owner or admin involvement.