Roles and permissions
Each person has an organization role and a separate domain role in each domain they join. The organization role governs workspace administration. The domain role governs the agents, flows, triggers, knowledge and shared connections in that domain.
An organization Member can be a domain Owner. An organization Owner can be a domain Viewer, or have no membership there. The two roles are independent. The basic domain member role is Viewer; domain members collectively includes all four domain roles. Neither term means the organization Member role.
Organization roles
| Role | What it grants |
|---|---|
| Owner | Organization administration, including inviting Admins and managing other Owners' access status. The last active Owner cannot be disabled. |
| Admin | Organization settings, AI providers and policies, budgets, organization knowledge, invitations for Members, and domain membership administration. Cannot invite Admins or disable/re-enable an Owner. |
| Member | Access to their own account, personal API keys and enabled personal features. Domain work is determined by their domain memberships. |
| Organization action | Member | Admin | Owner |
|---|---|---|---|
| Manage own profile, password, personal API keys and sign-ins | Yes | Yes | Yes |
| Manage organization settings, AI providers and policies | No | Yes | Yes |
| Manage organization-wide knowledge modules and decide OCR spending | No | Yes | Yes |
| Invite an organization Member | No | Yes | Yes |
| Invite an organization Admin | No | No | Yes |
| Disable/re-enable another Member or Admin | No | Yes | Yes |
| Disable/re-enable another Owner | No | No | Yes, while retaining an active Owner |
| Create a domain | If organization policy allows it; becomes its Owner | Yes | Yes |
| Assign any domain role or remove membership across the organization | No | Yes | Yes |
| View or use a domain's agents, flows, triggers, knowledge and sessions | Requires domain membership | Requires domain membership | Requires domain membership |
| Read someone else's personal chat | No | No | No |
Organization Owners and Admins can see the domain directory and administer domain membership without joining each domain. This does not grant access to its agents or session transcripts. A domain Owner can manage existing organization members within their own domain; inviting a new person into the organization still requires an organization Owner or Admin.
The invitation wizard offers Member and, for organization Owners, Admin. Its domain selector supports search/autocomplete; a single eligible domain is selected automatically. You can assign any domain role you are authorized to manage, or select Assign domain access later. Someone without domain membership can still use enabled personal features, but has no access to domain resources.
Domain roles
These roles apply only within the named domain. The matrix describes ordinary access; the approval and session exceptions below are part of the rules.
| Domain action | Viewer (member) | Operator | Editor | Owner |
|---|---|---|---|---|
| View agent/flow configuration and revision history | Yes | Yes | Yes | Yes |
| Start a session or run on a published agent/flow | Yes | Yes | Yes | Yes |
| View ordinary agent/flow sessions in the domain | Yes | Yes | Yes | Yes |
| Participate in a session they started or own | Yes | Yes | Yes | Yes |
| Participate in a teammate's or unowned automated session | No | Yes | Yes | Yes |
| Rename, archive, delete or set the outcome of a session | Own sessions | Own sessions | Own sessions | Any session in the domain |
| Create, edit, publish or archive agents and flows | No | No | Yes | Yes |
| Use Builder; view and join a linked Builder conversation | No | No | Yes | Yes |
| Start draft test drives, Flow sandbox runs and evaluations | No | No | Yes | Yes |
| View evaluation reports | Yes | Yes | Yes | Yes |
| Edit evaluation cases, learned rules, agent memory and knowledge | No | No | Yes | Yes |
| Read domain triggers, knowledge and webhook configuration | Yes | Yes | Yes | Yes |
| Manage triggers, subscriptions, catch-up batches and webhooks | No | Yes | Yes | Yes |
| Create/edit/publish domain knowledge bases, articles and modules | No | No | Yes | Yes |
| Manage shared connections and credentials | No | No | No | Yes |
| Open the agent/flow Integrations configuration panel | No | No | No | Yes |
| Add/remove domain members and assign any domain role | No | No | No | Yes |
| Manage domain settings and its approval policy | No | No | No | Yes |
| Decide domain-routed approvals under the default policy | No | Yes | Yes | Yes |
| Complete human tasks | No | Subject to the step's role floor | Subject to the step's role floor | Yes |
A domain must retain at least one Owner. Organization Owners and Admins also have the membership-administration authority described above; they still need the corresponding domain role to edit agents, manage triggers or manage domain knowledge.
Viewers and Operators inspect configuration through the same Markdown, JSON and form components with editing disabled. They are not shown draft-version labels, unpublished-change dots, publish controls or Builder editing actions. The Integrations configuration entry is hidden when the person cannot manage domain connections. Operators retain their separate trigger and webhook management controls.
Organization-wide knowledge modules and OCR spending decisions are organization responsibilities. Publishing domain articles, retrying ingestion and running domain preflight checks require Editor or Owner access in that domain. An article explicitly published with organization visibility may be used outside its home domain; that sharing does not grant permission to manage the home domain's knowledge.
Yekar-managed resources
A domain or agent marked as managed by Yekar remains visible and runnable to its domain members. Tenant roles, including organization and domain Owners, do not grant permission to change its definition or governance. Managed setup reads expose model and cap metadata, version information and integrations; prompts and tool wiring are withheld.
Organization administrators and domain Owners may add Viewers and Operators to a managed domain and switch between those two roles. Higher role assignments, changes to release-assigned higher roles, membership removal, domain metadata, archival and approval-policy edits require Yekar's release writer. Existing approval decisions still follow the domain's policy.
Editors and Owners assigned by Yekar may create and edit tenant-owned agents within a managed domain. Those agents count toward the agent limit. Managed domains and managed agents do not count toward the domain and agent limits. Trigger configuration on managed agents is protected; the existing enable/disable action remains available to authorized members.
Session visibility and participation
| Session | Who can view | Who can participate |
|---|---|---|
| Personal/free chat, including a conversation with no attached agent | Creator only | Creator only |
| Ordinary Agent or Flow session | Current members of its domain | Creator/recorded owner, plus domain Operators, Editors and Owners |
| Trigger, schedule, event or API session | Current members of its domain | Creator/recorded owner, plus domain Operators, Editors and Owners |
| Builder conversation linked to an agent | Anyone who can currently edit that agent | Anyone who can currently edit that agent |
| Builder conversation before an agent is linked | Creator, while retaining edit access to its domain | Creator, while retaining edit access to its domain |
| Evaluation replay | Current domain members, through evaluation reports | Nobody; start a new evaluation instead |
| Agent draft test drive | Current domain members | Editors and Owners only |
Participation includes sending messages, attaching files and cancelling turns or executions. It does not grant approval authority or permission to edit the agent. Renaming, archiving, deleting or setting an outcome requires the session's creator/recorded owner or a domain Owner, after passing the session's visibility check. Personal chats remain private even from organization Owners and Admins.
A trigger's owner is recorded when a session starts, separately from the actor that executed it. A Viewer who owns a trigger or schedule can therefore participate in its sessions, including after the trigger is deleted, while remaining a domain member. A personal API key acts as its authenticated owner. An automated session without a recorded human owner can be read by domain members and driven by Operators, Editors and Owners. Older sessions whose trigger ownership can no longer be recovered remain without an assigned owner.
A linked Builder conversation is shared across the agent's current Editors and Owners, regardless of who started it. Its transcript and stream are accessed through Builder's edit-permission check. Builder conversations are not exposed to other users through the service domain's general session list.
New human messages record their authenticated author; another person's message is not labelled as yours. Older messages without author records remain unattributed. Ownership of an automated session does not change which credentials its tools execute with; see Integrations & identity.
Archived agents and evaluation replays have additional restrictions on new messages. Losing the free-chat feature preserves existing personal transcripts but prevents new messages there. Historical sessions from the retired Apps feature retain organization-wide visibility and organization Owner/Admin control.
Cross-domain access and revocation
Permissions are evaluated against the resource's actual domain. An Editor in Support who is a Viewer in Finance can edit Support agents, inspect Finance configuration and run published Finance agents, but cannot edit Finance agents or participate in teammates' Finance sessions. With no Finance membership, they cannot open those resources at all. The MCP tool list and recent-agent suggestions also check current domain membership. Existing cross-domain agent connections remain identifiable by ID, name and domain ID, marked restricted: true; their other metadata is omitted.
A link to a child agent's session does not grant access to that child's domain. Organization-wide knowledge sharing also does not grant domain membership. Removing someone from a domain removes access to its sessions, including those they created or own; downgrading an Editor to Viewer removes Builder access and leaves ordinary session participation limited to their own sessions.
Dashboard read APIs accept an optional domainId, intersected with current memberships. An inaccessible domain returns empty lists and zero counts. With no selection, reads retain their membership union and existing personal-chat visibility; selecting a domain excludes domain-less chats. Run and turn history uses the domain stored on the run or session, including after an agent moves.
Authorization is checked on each new request, including direct URLs, API calls and mutations. Organization roles do not bypass session or agent domain checks. Feature availability, resource state and plan limits can further restrict an otherwise authorized action.
Approval authority follows identity
Participation and approval are separate permissions:
- Domain-routed approvals use the domain's approval policy. By default, Operators, Editors and Owners qualify. A domain Owner can change the minimum role or name additional domain members as approvers. Members who meet the minimum role continue to qualify when a named list is configured. A named Viewer can decide an agent approval, but a Flow gate's own minimum role still applies on top of the domain policy.
- Credential-owner approvals can be seen and decided only by the person whose supplied credential or personal sign-in the work uses, while they remain a member of the execution’s domain. Domain or organization seniority does not override that identity.
- Confirmations ask the person who initiated that attended turn to confirm an agent-selected write. Only that person can answer, including a Viewer; a confirmation does not grant general approval rights and is not listed in the Approvals inbox.
- Human tasks use the same domain approval policy, together with the step's assignee-role floor. Naming a member does not bypass that step-specific floor.
- A gate configured to disallow self-approval refuses its initiator even when that person otherwise qualifies.
Approval inboxes, pending counts and history use the same current membership and approval policy as decisions. The aggregate approval list, counts and history accept an optional domainId; a domain the caller has not joined returns an empty result. A flow or agent approval is selected by the domain stored on its run or session.
Organization-mandated tool approvals take precedence over agent confirmations. See How approvals are layered and Approvals.
Separate operational identities
A partner request made for a vouched person uses that person's organization and domain roles; a partner key does not itself supply those roles. Support access is time-limited, recorded, and restricted to its approved scope. See Partner tenant API and Support sessions.
Where to go next
- Domains, users & roles - create domains and assign access.
- Teams and offboarding - invitations, status changes and revocation.
- Sessions - inspect work and collaborate.
- Agent Builder - share an agent's authoring conversation.
Managed modules
Organization Owners and Admins can install an available module; only the Owner can upgrade or uninstall it. Installation adds the installer to the managed domain as an Operator. Module Operators can maintain tenant-owned knowledge in that domain. The managed knowledge base and its published contents stay readable but cannot be edited by tenant roles. Managed knowledge bases do not consume the knowledge-base count limit. Uninstall archives all agents in the module domain, including tenant-created agents, while retaining tenant knowledge and package data.