Bring a team on, and take a person off

A workspace is one organization; a team is a domain inside it. The domain owns the agents, the shared connections those agents act through, and the people allowed to touch them - so the order of setup is the order of ownership.

1. Create the domain

Settings → Domains → New domain. Organization admins can always create one; whether ordinary members can is an organization setting, and a member who does becomes its owner. A domain must always keep at least one owner.

2. Connect the team's accounts

On the domain's page, connect the integrations the team's agents will act through - the support mailbox, the shop, the channel. These are team accounts: the domain owns them, agents set to act as the team account use them, and nobody's departure takes them away. Only domain owners can connect or disconnect them.

An owner can also decide, per connection, whether the domain's agents may act as the person using them - Personal sign-ins → Members may sign in with their own account. See Identity.

3. Invite the people

Settings → Users → Invite user sends a one-time activation link that expires in 72 hours; the drawer also shows the link itself so you can pass it on when email is not an option. The person sets a password of at least ten characters - or, if their address already has a Yekar.AI account from another workspace, simply accepts. Google sign-in works once an account exists and holds an active membership; there is no sign-up through Google.

The invitation wizard asks for their organization role, then lets you choose their domain access. Click Add access for each domain: a row appears with a searchable Domain selector on the left and an Access role on the right. A single available domain is selected automatically, and each domain can appear only once. Review all assignments before sending. Choose Member and domain Editor for someone who needs to build agents. Leave the access list empty to invite without domain access; an organization Owner/Admin or a domain Owner can add access later.

The organization role defaults to Member. Admins manage users, AI providers and keys, organization defaults and cost; only an owner can invite someone as an admin. Being an organization admin does not put a person in any domain - they can see cost organization-wide, but they run a domain's agents only as its member.

An invitation name is an initial default. The name the person enters during signup, invitation acceptance, or Account settings takes precedence across their workspaces. Later invitations cannot overwrite it, and clearing a profile name does not restore an old invitation name.

4. Manage their domain role

Assign a domain role during invitation, or add and update members later on the domain's Members tab. Organization owners and admins can add, remove, and change members of any domain in their organization, assigning any domain role. Domain owners can do the same within their own domains. A domain must keep at least one owner. Managing membership does not itself grant access to the domain's agents.

If the invitation succeeds but assigning domain access fails, the wizard preserves the activation link and offers Retry access for each failed domain. Retrying leaves successful assignments in place and does not create another invitation.

Role	May
Viewer	See the domain's agents, flows and sessions, and run them
Operator	Viewer, plus decide approvals, manage triggers and webhooks
Editor	Operator, plus edit and publish agents and flows, manage knowledge
Owner	Editor, plus manage connections, members and the domain itself

Any domain member can start a published agent or flow. Viewers can participate in sessions they started or own; Operators, Editors and Owners can also participate in teammates' sessions. Each membership change is written to the audit trail. The complete matrices, including organization roles and approval exceptions, are in Roles and permissions.

5. Set the approver floor

The domain's approval policy defaults to Operator or higher. A domain Owner can instead choose another role floor or a named list of domain approvers; a Flow gate's own minimum role still applies. Make sure enough people qualify under the chosen policy and gate floors that unattended work does not depend on one person's inbox. See How approvals are layered.

Who sees what

Current domain members can inspect ordinary Agent and Flow sessions in their domains. Personal/free chats are private to their creator, including from organization Owners and Admins. Sending messages, attaching files and cancelling work require session participation; renaming, deleting and setting the outcome require the creator/recorded owner or a domain Owner. A trigger or schedule's recorded owner can participate in its sessions while remaining a domain member.

Builder conversations are shared with everyone who can currently edit the linked agent. Evaluation replays remain read-only. See the session access table for all session types.

One person, several workspaces

An account may hold memberships in several organizations. Sign in once and pick a workspace; switching rebinds the same session to another organization rather than widening it. A pending invitation shows beside the memberships until it is accepted.

Passwords

A signed-in person changes their own password under Settings → Account.

A person who is locked out uses Forgot your password? on the sign-in page. It always answers the same way - if that address has an account, a link is on its way - so the page never reveals who has an account here, and the emailed link lasts one hour, works once, and is replaced if they ask again. Setting a password this way signs them in, and it does not end sessions that are already signed in elsewhere; the page says so under the button. The same link sets a first password, for someone whose account has never had one.

If password reset is unavailable, the sign-in page directs you to contact your organization admin.

An invitation cannot be reissued to someone who has already activated - that would be a password reset in disguise.

Offboarding

Organization Owners and Admins can deactivate or re-enable other members from Settings → Users. Only an Owner can change another Owner's access status; nobody can change their own status or disable the last active Owner. Re-enabling a person requires an available seat. This changes access status; it does not delete the person's history.

• Their sign-in is refused and any live session ends at its next request. Memberships in other workspaces are unaffected.
• Every personal API key they hold stops working.
• Their personal sign-ins are deleted - every integration account they signed in to with their own credentials, in that organization. A token must not outlive the access it was granted under; a re-enabled person signs in again. Team accounts are untouched.
• An agent bound to The person using it for them then has nothing to act as: Fall back to the team account keeps running and says so, and otherwise its tools for that integration fail with a sign-in link.
• Their conversations, messages and audit rows remain, visible under the same rules as before.
• An approval routed to them personally becomes blocked, because the credential owner is unavailable; it expires on its own clock unless re-routed by cancelling and re-running.
• Schedules and event triggers they created keep running - a trigger's authority comes from its domain, not from its author. An API trigger fired with a personal API key uses that key's active owner; a path that needs to act as the trigger creator refuses when that creator is unavailable. The exception is a trigger firing an agent bound to The person using it: that fire runs as the trigger's creator, so when that person is unavailable its configured policy either uses the team account or skips the firing with person_unavailable.
• Team accounts are never orphaned: they belong to domains, not to people, so an agent acting through one keeps acting.

Removing someone from a domain revokes access to its sessions even when they created or own them; the domain must keep an Owner. Removing edit permission also revokes access to that domain's linked Builder conversations. Other current Editors and Owners can continue those Builder conversations.