> ## Documentation Index > Fetch the complete documentation index at: https://docs.textql.com/llms.txt > Use this file to discover all available pages before exploring further. # Role-Based Access Control (RBAC) > Manage who can access what in TextQL using roles and permissions Role-based access control (RBAC) is the method TextQL uses to manage what users can see and do within your organization. Instead of configuring permissions for each person individually, you define roles that reflect job functions, assign permissions to those roles, and then assign users to the appropriate role. ## What is Role-Based Access Control? RBAC is an access control model built around three concepts: 1. **Roles** — Named groupings that represent a job function or authority level (e.g., admin, member) 2. **Permissions** — Specific actions a role is allowed to perform (e.g., create connectors, manage members, view billing) 3. **Assignments** — Users are placed into a role; they inherit all of that role's permissions automatically When an employee joins, changes teams, or leaves, you update their role rather than hunting down individual permission settings. ## Benefits of RBAC * **Less per-user configuration** — Set permissions once on a role; every user assigned to it inherits them automatically. Role changes (e.g., someone moving teams) are a single update, not a sweep across individual accounts. * **Least-privilege by default** — Access is scoped to what each role needs. Sensitive areas like billing, SCIM, and org settings stay out of reach for general members without any extra effort. * **Consistent onboarding** — New users get the right access on day one by assigning a role, with no risk of missing a permission or over-granting access. * **Easier compliance** — Access is tied to named roles rather than individuals, making it straightforward to show auditors who can do what. See [Audit Log](/core/admin/audit-log) for a record of actions taken. ## Limitations of RBAC * **No record-level control** — Permissions apply to a whole resource type, not individual records. You cannot restrict a member to only their team's data within the same connector. * **Write bundles creation and editing** — Granting `write` on a resource lets users both create their own and edit any publicly shared version of it. These cannot currently be separated. * **Two roles may not fit every org** — The built-in admin/member split covers most cases, but organizations with many distinct access tiers may find the options limiting. * **Roles need periodic review** — Access that was appropriate when someone joined may not be correct six months later. Stale role assignments accumulate without active maintenance. ## When to Use RBAC TextQL's role system works well for organizations that have a clear split between users who manage the platform (admins) and users who use it to run analyses (members). Most deployments follow this pattern. Where it requires more thought is when different groups of members need meaningfully different levels of access — for example, a team that should be able to publish connectors versus one that should only be able to run chats. In those cases, configure the member role to the most restrictive common baseline and use [SCIM group mappings](/core/admin/scim) if your IdP can enforce the distinction at provisioning time. ## How to Configure RBAC in TextQL TextQL has two system roles. Each user in your organization is assigned exactly one. | Role | Description | | ---------- | --------------------------------------------------------------------------------------------------------------------------- | | **admin** | Full read and write access to all permissions across the organization | | **member** | Scoped access — can create and use core features, but cannot manage org-level settings, billing, SSO/SCIM, or other members | Roles are configured from **Settings → Roles**. Click **Manage Permissions** on any role to view or edit its permission set. ### Creating a Role 1. Navigate to **Settings → Roles** 2. Click **Create Role** and give it a name 3. Click **Manage Permissions** on the new role to configure its permission set 4. Toggle the permissions you want this role to have across each resource category ### Assigning a Role 1. Navigate to **Settings → Members** 2. Find the user and click the role dropdown next to their name 3. Select **admin** or **member** and confirm Changes take effect immediately. ### Permission Reference Each role is composed of granular permissions grouped by resource. Permissions follow a consistent pattern: `read` (public), `read_private` (private/org-wide), `write` (create/edit public), and `write_private` (create/edit private). Below is a full reference of every configurable permission and what it controls. Controls access to API keys used to authenticate programmatic requests to TextQL. | Permission | What it does | | --------------- | ----------------------------------------------------------------------------------- | | `read` | View and use public API access keys and any private ones explicitly shared with you | | `read_private` | View and use all private API access keys, even those not shared with you | | `write` | Create and edit public API access keys | | `write_private` | Create and edit private API access keys | *Default member permissions: `read` only* Controls visibility into your organization's usage and billing data. | Permission | What it does | | ---------- | ----------------------- | | `read` | View billing usage data | *Default member permissions: none — billing is admin-only* Controls access to conversation threads with Ana. | Permission | What it does | | --------------- | ------------------------------------------------------------------- | | `read` | View public chats and any private chats explicitly shared with you | | `read_private` | View all private chat conversations, even those not shared with you | | `write` | Create and edit public chats | | `write_private` | Create and edit private chats | *Default member permissions: `read`, `write`* Controls access to data source connections. See [Connectors](/core/datasources/the-connectors-page) for setup details. | Permission | What it does | | --------------- | ---------------------------------------------------------------------------- | | `read` | View public connectors and any private connectors explicitly shared with you | | `read_private` | View all private connectors, even those not shared with you | | `write` | Create and edit public connectors | | `write_private` | Create and edit private connectors | *Default member permissions: `write` (public connectors only)* Controls access to organization-level context prompts that Ana uses to give business-specific answers. See [Ontology](/core/ontology/overview). | Permission | What it does | | ---------- | ------------------------------------------------------- | | `read` | View organization context prompts | | `write` | Create, update, and delete organization context prompts | *Default member permissions: none* Controls access to persistent dashboards built from Ana's outputs. See [Dashboards](/core/how-it-works/dashboards). | Permission | What it does | | --------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | `read` | View public dashboards and any private dashboards explicitly shared with you; also enables chatting with a dashboard (requires `chat:write`) | | `read_private` | View all dashboards in the org, even those not shared with you | | `write` | Create your own dashboards **and** edit any public dashboard | | `write_private` | Edit **any** dashboard in the org, including restricted-access dashboards not shared with you | *Default member permissions: `write` (public dashboards)* Controls access to datasets — structured data files that can be uploaded or generated by Ana. | Permission | What it does | | --------------- | -------------------------------- | | `read` | View public datasets | | `read_private` | View private datasets | | `write` | Create and edit public datasets | | `write_private` | Create and edit private datasets | *Default member permissions: `write` (public datasets only)* Controls access to the feed — posts, comments, and agent activity visible across the organization. | Permission | What it does | | --------------- | ------------------------------------------------------------------------------ | | `read` | View feed posts and comments | | `read_private` | View private feed channels and their posts, even when not explicitly invited | | `write` | Create posts, comments, and manage agents | | `write_private` | Manage private feed channels and their posts, even when not explicitly invited | *Default member permissions: `write`* **Chat-level access inheritance** Feed post visibility is also gated by chat permissions. A member with feed `read` access will only see a post if they also have `read` access to every chat referenced by that post. Posts that have no chat reference (e.g. plain text posts) are always visible to anyone with feed `read` access. Admins bypass this check and see all posts. Controls access to MCP (Model Context Protocol) server configurations used to extend Ana with external tools and data sources. | Permission | What it does | | ---------- | -------------------------------------- | | `read` | Read MCP server configurations | | `write` | Write/modify MCP server configurations | *Default member permissions: `read`* Controls visibility and management of users in your organization. | Permission | What it does | | ---------- | -------------------------------------------- | | `read` | View organization members | | `write` | Manage organization members (invite, remove) | *Default member permissions: `read`* Controls access to notification preferences and in-app alerts. | Permission | What it does | | ---------- | ------------------------------------------- | | `read` | View own notifications and preferences | | `write` | Mark notifications read, update preferences | *Default member permissions: `write`* Controls access to the ontology — the structured map of your business data. See [What is Ontology](/core/ontology/overview). | Permission | What it does | | --------------- | --------------------------------------------------------------------------------------- | | `read` | View public ontology schema and any private ontologies explicitly shared with you | | `read_private` | View all private ontologies, even those not shared with you | | `write` | Create, update, and delete ontology schema, objects, attributes, metrics, and relations | | `write_private` | Create and edit private ontologies | *Default member permissions: `read`* Controls access to top-level organization settings such as name, appearance, and global configuration. | Permission | What it does | | ---------- | ---------------------------- | | `read` | View organization settings | | `write` | Manage organization settings | *Default member permissions: none — org settings are admin-only* Controls access to installable packages that extend TextQL's functionality. | Permission | What it does | | ---------- | --------------------------- | | `read` | View org packages | | `write` | Install/remove org packages | *Default member permissions: `read`* Controls access to automated analysis workflows. See [Playbooks](/core/how-it-works/playbooks). | Permission | What it does | | --------------- | -------------------------------------------------------------------------- | | `read` | View public playbooks and any private playbooks explicitly shared with you | | `read_private` | View all private playbooks, even those not shared with you | | `write` | Create and edit public playbooks | | `write_private` | Create and edit private playbooks | *Default member permissions: `write` (public playbooks only)* Controls whether a user can view or modify role configurations themselves. | Permission | What it does | | ---------- | -------------------- | | `read` | View role settings | | `write` | Manage role settings | *Default member permissions: `read`* Controls access to SCIM provisioning tokens and OAuth clients used for automated user lifecycle management. See [SCIM](/core/admin/scim). | Permission | What it does | | ---------- | ----------------------------------------------- | | `read` | View SCIM tokens and OAuth clients | | `write` | Create and revoke SCIM tokens and OAuth clients | *Default member permissions: none — SCIM is admin-only* Controls visibility into organization-level usage metrics and ACU consumption data. | Permission | What it does | | ---------- | -------------------------------------------- | | `read` | View organization usage metrics and ACU data | *Default member permissions: none — usage data is admin-only* Controls which AI models members can use and whether they can override the org default. See [Model Management](/core/admin/models) for full model management options. | Permission | What it does | | ----------------------- | ------------------------------------------------------------------------- | | `allow_model_switching` | Users can override the default model in chat | | **Default Model** | The model used when this role starts a new chat (defaults to Org Default) | | **Allowed Models** | Which models this role can select from | *Default member permissions: model switching disabled; allowed models and default set by admin* ### Provisioning Roles at Scale with SCIM If your organization uses an identity provider like Okta or Azure AD, you can provision and deprovision users automatically and map IdP groups to TextQL roles using [SCIM](/core/admin/scim). This is the recommended approach for organizations with more than \~20 users, as it keeps roles in sync with your IdP without manual intervention. ## RBAC Best Practices **Default new users to member** When unsure which role to assign, start with member and escalate to admin only when explicitly needed. Admin access should be limited to people who manage the organization's settings and security configuration. **Base roles on job function, not individuals** If you find yourself needing highly customized permissions for a single person, it is usually a sign that the permission boundary is better handled at the connector or context level rather than a new role. **Review role assignments periodically** Run a quarterly review of your member list and their assigned roles. Look for users who have moved teams or changed responsibilities. The [Audit Log](/core/admin/audit-log) can help surface accounts that have not been active recently. **Pair with SSO and SCIM for lifecycle management** Manual role assignment works for small teams, but human error accumulates. Connecting TextQL to your IdP via [SSO](/core/admin/sso) and [SCIM](/core/admin/scim) ensures that when someone leaves the company or changes teams, their TextQL access updates automatically. **Restrict private resource access carefully** `read_private` and `write_private` permissions grant org-wide visibility into resources that individual users have intentionally kept private. Grant these sparingly and only to roles that genuinely need cross-user visibility.