Ingestly uses role-based access control (RBAC) to manage what users can do. Each user is assigned a role, and each role has a set of permissions.
Built-in roles
Every organization comes with four built-in roles. Built-in roles cannot be edited, renamed, or deleted, but their permissions can be inspected, and they are always available when you invite or assign teammates.
| Role | Best for | What they can do |
|---|
| Admin | Organization owners | Full access: members, roles, billing, integrations, and all document processing |
| Member | Everyday users | Build and run the full document workflow (pipelines, templates, documents, runs, reviews, alert rules, comments). Cannot manage members, billing, or integrations |
| Reviewer | People who validate results | Work the review queue (approve or reject), comment, and view the surrounding data. Cannot build or change pipelines, templates, or documents |
| Viewer | Read-only stakeholders | View pipelines, documents, runs, reviews, templates, alert rules, and comments. Cannot make changes |
In the roles list at Settings → Roles, built-in (system) roles have their Edit and Delete actions disabled, but the Permissions action remains available. It opens a read-only view where the toggles are disabled and you cannot save (the footer shows a single Close button), so you can review exactly which permissions a built-in role grants without modifying them.
Connectors, API keys, and webhook signing keys are managed by Admins only. The Member, Reviewer, and Viewer roles cannot access these credentials.
Permission model
Permissions follow the format Group.Resource.Action. For example, Core.Pipeline.Read grants read access to pipelines.
Permission groups
| Group | Resources | Description |
|---|
| Core | Pipeline, Document, Template, Workspace, Run, Review, AlertRule | Document processing resources |
| Account | User, Role, ApiKey, WebhookSigningKey, Organization | Organization management |
| ApiKeyAuth | Trigger | API key authentication actions (e.g., submitting documents via webhook trigger) |
| Subscription | Plan | Subscription and billing management |
Actions
Each resource supports up to four actions:
| Action | Description |
|---|
| Read | View the resource |
| Create | Create new instances |
| Update | Modify existing instances |
| Delete | Remove instances |
Implied permissions
Some permissions imply others. For example:
Core.Pipeline.Update implies Core.Pipeline.Read. You can’t update what you can’t seeCore.Pipeline.Delete implies Core.Pipeline.ReadCore.Pipeline.Create implies Core.Pipeline.Read
This means you don’t need to explicitly grant Read when granting Create, Update, or Delete.
Baseline permissions
A few permissions are granted to every user automatically and cannot be revoked by a role. In the role permissions dialog, these show up as toggles that are always on and cannot be unchecked.
Today, the only baseline permission is:
Core.Workspace.Read: every user can see the workspaces they belong to.
Baseline permissions are enforced by Ingestly itself, not by the role. You do not need to grant them when creating a custom role, and you cannot take them away.
Complete permission reference
Core permissions
| Permission | Description |
|---|
Core.Pipeline.Read | View pipelines and their configurations |
Core.Pipeline.Create | Create new pipelines |
Core.Pipeline.Update | Edit pipeline settings, edit the workflow in the editor, activate/deactivate |
Core.Pipeline.Delete | Delete pipelines |
Core.Document.Read | View uploaded documents |
Core.Document.Create | Upload documents |
Core.Document.Update | Re-run documents |
Core.Document.Delete | Delete documents |
Core.Run.Read | View runs |
Core.Run.Create | Start pipeline runs |
Core.Run.Update | Cancel runs |
Core.Review.Read | View review tasks |
Core.Review.Update | Approve or reject review tasks |
Core.Template.Read | View templates |
Core.Template.Create | Create templates |
Core.Template.Update | Edit templates |
Core.Template.Delete | Delete templates |
Core.Workspace.Read | View workspaces (baseline, granted to every user) |
Core.Workspace.Create | Create new workspaces |
Core.Workspace.Update | Rename workspaces |
Core.Workspace.Delete | Delete workspaces |
Core.AlertRule.Read | View alert rules |
Core.AlertRule.Create | Create new alert rules |
Core.AlertRule.Update | Edit alert rules |
Core.AlertRule.Delete | Delete alert rules |
Account permissions
| Permission | Description |
|---|
Account.User.Read | View organization members |
Account.User.Create | Invite users |
Account.User.Update | Edit user roles |
Account.User.Delete | Remove users |
Account.Role.Read | View roles |
Account.Role.Create | Create roles |
Account.Role.Update | Edit roles and permissions |
Account.Role.Delete | Delete roles |
Account.ApiKey.Read | View API keys |
Account.ApiKey.Create | Generate API keys |
Account.ApiKey.Update | Edit API keys |
Account.ApiKey.Delete | Delete API keys |
Account.WebhookSigningKey.Read | View webhook signing keys |
Account.WebhookSigningKey.Create | Generate signing keys |
Account.WebhookSigningKey.Delete | Delete signing keys |
Account.Organization.Read | View organization details |
Account.Organization.Update | Update organization name and settings |
Account.Organization.Delete | Delete the organization |
API key auth permissions
| Permission | Description |
|---|
ApiKeyAuth.Trigger.Create | Submit documents via webhook trigger using an API key |
Subscription permissions
| Permission | Description |
|---|
Subscription.Plan.Read | View subscription and billing details |
Subscription.Plan.Create | Create subscriptions |
Creating a custom role
- Go to Settings → Roles
- Click New Role
- Enter a role name
- Select the permissions to grant
- Click Save
A small number of toggles in the permission grid appear always on and cannot be unchecked. These are
baseline permissions that Ingestly grants to every user.
Start with a minimal set of permissions and add more as needed. It’s easier to grant additional access than to revoke it.
