Documentation Index
Fetch the complete documentation index at: https://docs.atomicagi.com/llms.txt
Use this file to discover all available pages before exploring further.
Use this page to manage organization access with role-based and feature-based permission control.
Questions this page should answer
- Who currently has access to this organization?
- How do I invite a new member with the right scope?
- How do
None, View only, and Full actually affect access?
Before you use this page
- In the app, open Organization settings and select
Members.
- Confirm you have members write access.
- Check seat availability before bulk invites.
What this page controls
- Member directory (
Email, Role, Project access, Joined at, Actions).
- Invite flow with role + workspace permissions + project permissions.
- Edit permissions flow for existing members.
- Member removal.
Invite members flow
Invite members opens a dialog where you define access before sending invites.
How to invite correctly
- Add one or multiple emails.
- Select role:
Admin: full access across workspace and projects.
Member: granular permissions are applied.
- Set
Workspace permissions (General, Integrations, Members, Projects, Billing).
- Select project access.
- For each selected project, set feature/settings permissions.
Edit permissions flow
Use the shield icon in the members table to open Edit permissions for an existing member.
What you can edit
- Role (
Admin or Member).
- Workspace permission scopes.
- Project access selection.
- Per-project feature + settings permission scopes.
Permission scopes explained
The same 3 states are used across workspace and project permission rows:
| Scope | What it means | Typical use case |
|---|
None | Feature is hidden/inaccessible for that member in that scope | Restrict access entirely |
View only | Member can see/read but cannot perform write actions (create/edit/delete/run) | Analyst/reviewer access without write rights |
Full | Member can view and perform write actions | Owner/operator who executes work |
Workspace-level permissions
These control access to organization settings sections:
General: /settings/organization/general
Integrations: /settings/organization/integrations
Members: /settings/organization/members
Projects: /settings/organization/projects
Billing: /settings/organization/billing
Project feature permissions
These control feature access inside selected projects.
Project settings permissions
These control access to project settings tabs:
| Permission key | UI label | Docs link |
|---|
SETTINGS_GENERAL | General | /settings/project/general |
SETTINGS_MEMBERS | Members | /settings/project/members |
SETTINGS_DATA_SOURCES | Data sources | /settings/project/data-sources |
SETTINGS_PUBLISHING | Publishing | /settings/project/publishing |
Practical permission patterns
- Client reviewer:
View only on reporting features, None on members/billing, limited project scope.
- SEO operator:
Full on data/technical/workflows in assigned projects, None on billing.
- Organization admin:
Admin role when they need global control.
Quick weekly checklist
- Resolve stale pending invites.
- Audit members with broad
Full scopes.
- Remove access for users no longer on account.
- Re-check project assignment breadth for each member.
Keep in mind
- Organization members can have different scopes per project.
- Role and permission scopes interact:
Admin bypasses granular restrictions.
- Seat limits can block new invites until capacity is increased.
Where to go next