Enterprise Feature — RBAC is available on superglue Enterprise plans. Contact us to learn more. Core concepts
Base roles
Every user has exactly one base role. superglue ships with three base roles:
| Base role | Description |
|---|
| Admin | Full access to everything. Bypasses all RBAC checks. Cannot be edited. |
| Member | Default for organization team members. Starts with access to all tools and systems. Tool and system allowlists can be narrowed to restrict access. |
| End User | Default for external users (portal, end-user API keys). Starts with no access. Tool and system allowlists must be explicitly populated to grant access. |
Custom roles
You can create custom roles for specific use cases — “Sales Team” (only CRM tools), “Finance” (only accounting systems), “External Partner” (read-only access to specific APIs). Custom roles are fully editable and can be assigned on top of a user’s base role.
How allowlists work
Every role defines two allowlists:
- Tools — which tools the role can execute
- Systems — which systems the role can access, and at what level
If a tool or system isn’t on the allowlist, it’s denied. There are two modes for each:
Tools:
"ALL" — every tool is allowed, including tools created in the future- Specific list — only the listed tools are allowed; new tools are NOT auto-included
Systems:
"ALL" — every system is allowed at read-write level, including future systems- Specific map — per-system access levels; unlisted systems are denied
System access levels
Each system in the allowlist has an access level:
| Level | Meaning |
|---|
"read-write" | All HTTP methods allowed |
"read-only" | Only GET and HEAD; POST/PUT/PATCH/DELETE blocked |
{ rules: [...] } | Custom rules that gate access (see below) |
Multi-role evaluation
Users can have multiple roles (one base role plus any number of custom roles). When a user has multiple roles, resolution is union — most permissive wins:
| Layer | Semantics | Example |
|---|
| Tools | Union | If role A allows tool X and role B doesn’t, tool X is allowed |
| Systems | Union | If role A gives read-only and role B gives read-write, result is read-write |
| Custom rules | Per-role union | If any role’s complete rule set allows the request, it goes through |
- Within a single role, all custom rules for a system must pass (AND logic)
- Across roles, if any role fully allows the request, it goes through (OR logic)
Setting up roles
Example: Restricting member access
By default the Member base role has access to all tools and systems. To restrict it, switch from "ALL" to specific allowlists:
{
"name": "Member",
"tools": "ALL",
"systems": {
"salesforce": "read-write",
"hubspot": "read-write"
}
}
Example: Granting end user access
The End User base role starts with empty allowlists. Add entries to grant access:
{
"name": "End User",
"tools": ["get-contacts", "search-deals"],
"systems": {
"salesforce": "read-only",
"hubspot": "read-only"
}
}
Example: Custom role for a team
Create a custom role that grants access to specific tools and systems:
{
"name": "Sales Team",
"description": "CRM-only access",
"tools": ["get-contacts", "search-deals", "update-deal"],
"systems": {
"salesforce": "read-write",
"hubspot": "read-only"
}
}
Custom rules
For fine-grained control beyond read-only/read-write, use custom rules on a per-system basis:
{
"name": "Engineering",
"tools": "ALL",
"systems": {
"salesforce": {
"rules": [
{
"name": "Block DELETE requests",
"expression": "stepConfig.method !== 'DELETE'",
"isActive": true
}
]
}
}
}
"ALL"). A system entry is either an access level OR custom rules, never both.
Writing expressions
Expressions receive a stepConfig object with the fully resolved request details:
| Field | Type | Description |
|---|
stepConfig.url | string | Resolved URL |
stepConfig.method | string | HTTP method |
stepConfig.headers | Record<string, string> | Resolved request headers |
stepConfig.queryParams | Record<string, string> | Query parameters |
stepConfig.body | unknown | Resolved request body |
stepConfig.systemId | string | System ID |
The expression must return a truthy value to allow the request. If it returns falsy or throws, the request is blocked (fail-closed).
Example expressions
// Block DELETE requests
stepConfig.method !== "DELETE"
// Only allow GET requests to read endpoints
stepConfig.method === "GET" && stepConfig.url.includes("/api/v1/read")
// Block requests with a specific header
!stepConfig.headers["x-dangerous-header"]
// Block a specific datasource ID in the body
!(typeof stepConfig.body === "object" && stepConfig.body?.datasource?.id === "blocked-id")
Auto-append on resource creation
When a user creates a new tool or system, superglue automatically adds it to the creator’s base role — but only if that base role uses specific allowlists (not "ALL"):
- New tool → appended to the creator’s base role tool list
- New system → appended to the creator’s base role system map with read-write access
This ensures users on restricted allowlists automatically get access to resources they create.
Managing roles
Via the dashboard
- Navigate to Control Panel → Organization
- Team members and end users are listed with their current roles
- Click a user to assign or remove roles
- Use the Roles section to create, edit, or delete custom roles
