Team Management¶
Collaborate with team members through workspaces with role-based access control, invitation workflows, and data isolation.
Overview¶
Team Management provides:
- Workspaces β Isolated environments for team collaboration
- Roles β Admin and Guest permissions
- Invitations β Email-based team member invitations
- Workspace Isolation β Data scoped per workspace
- Role-Based Access β Different permissions per role
Workspaces¶
What is a Workspace?¶
A workspace is an isolated environment where team members collaborate. Every user belongs to exactly one workspace.
| Aspect | Description |
|---|---|
| Owner | The user who created the workspace |
| Scope | All data is isolated per workspace |
| Identification | UUID assigned to the workspace |
| Creation | Automatic when user signs up |
Workspace Creation¶
When a new user signs up:
- They automatically become the admin of their own workspace
- Their
user_idbecomes theworkspace_id - They can invite other team members to join
Data Isolation¶
All data in the platform is scoped to the workspace:
- AI agents and their configurations
- Voice agents and call logs
- Payroll employees and settings
- Perks and transactions
- Workflows and executions
- Assets and licenses
Roles¶
Admin Role¶
Full management privileges:
| Permission | Description |
|---|---|
| Invite Members | Send team invitations |
| Change Roles | Promote/demote team members |
| Remove Members | Remove team members from workspace |
| Write Operations | Create, update, delete all workspace data |
| Manage Settings | Configure workspace settings |
| View Analytics | Access all reports and analytics |
Guest Role¶
Read-only access:
| Permission | Description |
|---|---|
| View Data | Read all workspace data |
| View Members | See team member list |
| Cannot Write | No create, update, or delete operations |
| Cannot Manage | No team management capabilities |
Role Enforcement¶
Role-based access is enforced at multiple levels:
- UI Level β Buttons and forms are hidden/disabled for guests
- API Level β Edge functions verify admin role for write operations
- Database Level β Row-Level Security (RLS) policies enforce permissions
Inviting Team Members¶
Sending Invitations¶
- Navigate to Settings β Team
- Enter the team member’s email address
- Select a role (Admin or Guest)
- Click Send Invitation
Invitation Process¶
- Admin sends invitation β Edge function creates pending record
- Email sent β Invited user receives invitation email
- User signs up β If new user, they create an account
- Invitation accepted β User joins the workspace with the assigned role
Invitation Status¶
| Status | Description |
|---|---|
| Pending | Invitation sent, not yet accepted |
| Active | Invitation accepted, user is a team member |
Re-Inviting¶
If a pending invitation needs to be resent:
- The old pending record is deleted
- A new invitation is created
- A fresh email is sent
Managing Team Members¶
Viewing Members¶
- Navigate to Settings β Team
- View the list of active and pending members
| Column | Description |
|---|---|
| Member’s email address | |
| Role | Admin or Guest badge |
| Status | Active or Pending |
| Joined | Date joined |
Changing Roles¶
- Find the team member in the list
- Click the role dropdown
- Select the new role
Last Admin Protection
You cannot demote the last admin in a workspace. At least one admin must remain.
Removing Members¶
- Find the team member in the list
- Click the delete icon
- Confirm the removal
Self-Protection
You cannot remove yourself from the workspace. Another admin must perform this action.
Safety Rules¶
Last Admin Protection¶
- Cannot demote the last admin
- Cannot remove the last admin
- System ensures at least one admin exists
Self-Protection¶
- Cannot change your own role
- Cannot remove yourself from the workspace
- Prevents accidental lockout
Email Verification¶
- Invitation email must match the user’s account email
- Prevents unauthorized workspace access
- Ensures proper identity verification
No Privilege Escalation¶
- Role is never modified during invitation acceptance
- Prevents invited users from granting themselves admin
- Role is set only by existing admins
Accepting Invitations¶
Invitation Flow¶
- User receives invitation email with a unique token
- User clicks the link in the email
- If not logged in, redirects to signup page
- If logged in, verifies email matches invitation
- User accepts the invitation
- User is added to the workspace with the assigned role
Invitation Token¶
- Unique token generated for each invitation
- Token is valid for a limited time
- Token is verified against the user’s email
Team Context¶
The TeamProvider context provides:
| Property | Description |
|---|---|
| teamRole | Current user’s role (admin/guest) |
| workspaceId | Current workspace ID |
| isAdmin | Boolean: is user an admin? |
| isGuest | Boolean: is user a guest? |
| isLoading | Boolean: is data loading? |
| members | Array of team members |
| refreshTeamData | Function to reload team data |
Best Practices¶
- Start with admin β The workspace creator should be an admin
- Use guests for oversight β Guests can view data without modifying it
- Limit admin count β Keep admin count to those who need full access
- Regular audits β Review team member list periodically
- Remove inactive members β Clean up members who no longer need access
What’s Next¶
- Settings β Configure workspace settings
- API Keys β Manage API access
- Workflows β Automate team-related tasks
Still questions? Ask on Discord or explore tutorials