Role-Based Access Control

NodeLoom provides role-based access control (RBAC) with four built-in roles, team-scoped permissions, SCIM 2.0 provisioning, and API token authentication with IP allowlisting.

Roles

Every user in a NodeLoom workspace is assigned one of four roles. Roles are hierarchical -- higher roles inherit all permissions from lower roles.

Role	Description
Admin	Full access to all workspace features including user management, billing, security settings, audit logs, and all workflow operations.
Builder	Can create, edit, and delete workflows. Can manage credentials and configure integrations. Cannot access user management or billing.
Operator	Can execute workflows and view execution history. Cannot create or modify workflow definitions or credentials.
Viewer	Read-only access. Can view workflows, execution history, and dashboards but cannot make any changes or trigger executions.

Permission Matrix

The following table shows the complete permission matrix for all four roles. A checkmark indicates that the role has access to the corresponding action.

Permission	Admin	Builder	Operator	Viewer
View workflows	Yes	Yes	Yes	Yes
View execution history	Yes	Yes	Yes	Yes
View dashboards	Yes	Yes	Yes	Yes
Execute workflows	Yes	Yes	Yes	No
Test individual nodes	Yes	Yes	Yes	No
Create workflows	Yes	Yes	No	No
Edit workflows	Yes	Yes	No	No
Delete workflows	Yes	Yes	No	No
Activate/deactivate workflows	Yes	Yes	No	No
Manage credentials	Yes	Yes	No	No
Configure integrations	Yes	Yes	No	No
Manage team members	Yes	No	No	No
Assign roles	Yes	No	No	No
Access billing	Yes	No	No	No
Configure security settings	Yes	No	No	No
View audit logs	Yes	No	No	No
Manage SCIM provisioning	Yes	No	No	No
Manage API tokens	Yes	No	No	No
Configure SSO/OAuth	Yes	No	No	No

Team-Scoped Access

Permissions in NodeLoom are scoped to teams. Each team is an isolated workspace with its own set of workflows, credentials, execution history, and member roles. A user can belong to multiple teams with different roles in each.

Team scoping ensures that a Builder in Team A cannot see or modify workflows belonging to Team B, even if they are in the same organization. Admins can manage cross-team visibility in the organization settings.

Default team

When a new user signs up, they are placed in a default personal team. Organization admins can then invite them to additional teams with specific roles.

SCIM 2.0 Provisioning

NodeLoom supports SCIM 2.0 for automated user provisioning and deprovisioning. This allows your identity provider to automatically create, update, and remove NodeLoom accounts when changes are made in your directory.

Supported Providers

Provider	Status
Okta	Fully compatible
Azure AD	Fully compatible
OneLogin	Fully compatible
Other SCIM 2.0 providers	Compatible via standard SCIM endpoints

Group-to-Role Mapping

SCIM groups from your identity provider can be mapped to NodeLoom roles. When a user is added to a group in your directory, they automatically receive the corresponding role in NodeLoom.

Example group-to-role mapping

{
  "scimGroupMappings": [
    { "group": "Engineering", "role": "BUILDER", "team": "Backend" },
    { "group": "DevOps", "role": "OPERATOR", "team": "Infrastructure" },
    { "group": "QA", "role": "VIEWER", "team": "Backend" },
    { "group": "Platform-Admins", "role": "ADMIN", "team": "*" }
  ]
}

Wildcard team mapping

Use * as the team value to grant a role across all teams. This is typically used for organization-wide admin access.

API Token Authentication

For programmatic access, NodeLoom supports bearer token authentication. API tokens inherit the role and team scope of the user who created them.

Using an API token

curl -H "Authorization: Bearer <your-api-token>" \
  https://your-instance.nodeloom.io/api/v1/workflows

IP Allowlisting

API tokens can be restricted to specific IP addresses or CIDR ranges. Requests from non-allowed IPs are rejected with a 403 Forbidden response, even if the token is valid.

Token with IP allowlist

{
  "name": "CI/CD Pipeline Token",
  "role": "OPERATOR",
  "allowedIPs": [
    "10.0.0.0/8",
    "192.168.1.100/32"
  ],
  "expiresAt": "2026-12-31T23:59:59Z"
}

Token security

API tokens provide the same level of access as the user who created them. Treat them like passwords -- never commit them to version control, and rotate them regularly.

Guardrails

Audit Logs