Role-Based Access Control (RBAC)

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 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 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. 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

Role changes apply to new sign-ins immediately, but an active session carries its roles in a token that lives for 15 minutes, so an already signed-in user may not see the change until that token renews. Signing out and back in applies it at once. Existing API keys are not affected at all — their roles are fixed when the key is created, so a promoted user needs a new key. See API Keys.

​

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.

​

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. 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 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 and 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.