Users and permissions
A Jootle instance starts as single-user (you). For individuals, that’s where it stays.
For teams, you add users and assign roles. This chapter covers how.
Adding a user
Section titled “Adding a user”From Settings → Users, click Invite user.
You’ll provide:
- Email address. Used for the invitation and as the user’s primary identifier.
- Display name. What your AI will call them.
- Role. See below.
An invitation email goes out. The recipient clicks the link, sets a password (or signs in with an OAuth provider you’ve enabled), and lands in your instance with whatever role you gave them.
The roles
Section titled “The roles”There are four built-in roles. Each is a coarse-grained permission set; finer permissions can be assigned per-user (see below).
Owner. That’s you, the person who provisioned the instance. There’s one Owner per instance. Owners can do everything, including billing changes, role assignments, instance deletion. You cannot demote yourself below Owner; instead you transfer ownership to someone else (advanced, rarely done).
Admin. Can do nearly everything except billing and instance-level destructive operations. Admins manage users, install toolkits, configure integrations. A senior team member or a trusted operator typically gets Admin.
Member. The standard role for team members. Can use the assistant, create projects, manage their own tasks, draft and send messages (subject to approval gates). Cannot manage users, install toolkits, or change integration credentials. Most team members are Members.
Viewer. Read-only access. Can see what’s in the instance but cannot edit, send, or create. Useful for stakeholders who want visibility but shouldn’t be able to act.
What each role can do
Section titled “What each role can do”A compressed view:
| Action | Viewer | Member | Admin | Owner |
|---|---|---|---|---|
| Chat with the AI | ✓ | ✓ | ✓ | ✓ |
| Create projects, tasks, lists | ✓ | ✓ | ✓ | |
| Send email, post to channels | ✓ (gated) | ✓ | ✓ | |
| Install toolkits | ✓ | ✓ | ||
| Configure integrations | ✓ | ✓ | ||
| Invite, edit, remove users | ✓ | ✓ | ||
| Change roles (except Owner) | ✓ | ✓ | ||
| Change billing | ✓ | |||
| Delete instance | ✓ |
Fine-grained permissions
Section titled “Fine-grained permissions”For most teams, role-based permissions are enough. For teams that need more, you can layer specific permissions on top of a role.
Examples:
- A Member who should be able to install toolkits in their domain (“the marketing manager can install marketing toolkits”).
- A Member who should NOT be able to send certain outbound mail (“the intern’s drafts always require Admin approval”).
- A Viewer who should be able to add comments to artifacts (but not edit them).
These per-user overrides are set on the user’s detail page in Settings.
Approval gates and team users
Section titled “Approval gates and team users”When a team member’s action triggers an approval gate (Approvals and gates), the gate routes to whoever has the right to approve it. Usually:
- Routine sends gate to the user themselves (they review their own).
- Higher-stakes sends gate to an Admin or the Owner.
- Spend-related actions gate to the Owner.
You can configure routing per gate-type (“emails to external clients always route to me for approval”), and you can delegate (“Anna can approve emails to clients on the customer list”).
Removing a user
Section titled “Removing a user”From the user’s detail page, click Remove. You’ll be asked what to do with their data:
- Reassign their owned items to another user. Tasks they owned, drafts they were working on, artifacts they created.
- Archive their owned items. Items become read-only and owned by “Archived users”.
- Delete their owned items. Irreversible.
Reassign is the safest default and the most common.
The user’s account is disabled immediately; they lose access. Their authored history (messages, decisions, contributions) stays in the activity log under their name, since rewriting history would compromise audit trails.
Two-person households and shared workspaces
Section titled “Two-person households and shared workspaces”A common pattern: a household where two adults share a Jootle. Each gets a user account; both have Owner or Admin role (Owner is sole, so usually one is Owner and one is Admin).
Each person’s DM-style conversations are private to them. Projects, programs, contacts, and shared toolkits (Recipes, Travel, Finance) are shared. The two AIs are the same brain seeing both perspectives.
For households, this is usually the right model. For businesses, it’s usually one Owner (the founder, the operator) and multiple Members.
Single sign-on (SSO)
Section titled “Single sign-on (SSO)”Enterprise plans support SSO via SAML or OIDC. Configure under Settings → SSO. Once enabled, invited users sign in through your IdP instead of setting a Jootle password.
SSO doesn’t change roles or permissions; it just changes how users authenticate. Role assignment still happens inside Jootle.
Per-instance vs. per-Jootle
Section titled “Per-instance vs. per-Jootle”Roles are scoped to a single instance. If you run multiple instances (rare for individuals, occasional for businesses), each one has its own user list and role assignments.
If you’d like one person to admin across multiple instances, they need an account in each. There’s no cross-instance “super admin” role.
What your AI knows about each user
Section titled “What your AI knows about each user”Your AI keeps a sense of who each team member is, what they tend to ask for, their preferences (terse vs. detailed, formal vs. casual). This is per-user, learned from their conversations, scoped privately.
So when the marketing manager and the operations manager both ask “give me a status update”, the resulting style and emphasis are different. Same brain, different lenses.