Permissions and Access Control
Access in FluidGrids is role-based. Every request the web app, the CLI, the SDKs, the MCP server, webhooks or your own scripts make is checked at the API gateway against the caller's roles in the workspace. The app only hides what the gateway would refuse anyway, so a hidden menu item is never the only thing standing between a user and a resource.
This page is the administrator's reference. For what each role sees day to day, see Roles and Permissions.
How a permission is decided
- Roles are assigned per workspace. A person can hold different roles in different workspaces, and several roles in the same workspace.
- A role grants a level on each resource type. The levels are Viewer, Editor and Admin. A role that does not list a resource type has no access to it.
- Each action needs a minimum level. As a rule, reading and listing need Viewer; creating, updating, running and retrying need Editor; and deleting needs Admin. A few actions differ: publishing a workflow and revealing a workflow variable's value need Admin, and even reading log-stream destinations or secrets-provider settings needs Editor.
- Several roles add up. The highest level any of your roles grants on a resource type is the one that applies.
Activating and deactivating a workflow version are updates, so any role with Editor on workflow can do them.
Workspace owners and workspace admins hold every permission in their workspace, whatever product roles they also have.
The six FluidGrids roles
The tables below are generated from the FluidGrids role catalog, the same definitions the gateway enforces.
| Role | What it is for |
|---|---|
| FluidGrids Automation Owner | Full control of FluidGrids in this workspace, including the connector registry, execution usage, and automation settings. |
| FluidGrids Automation Lead | Approves, activates, and retires workflow versions, arms triggers and schedules, and governs day-to-day automation change. |
| FluidGrids Workflow Designer | Builds workflows on the canvas, configures nodes and triggers, and test-runs drafts, without deleting published automations. |
| FluidGrids Integration Engineer | Curates the connector catalog, registers custom node endpoints and operations, and works the submitted node-package queue. |
| FluidGrids Run Operator | Triages failed runs, retries nodes and webhook deliveries, cancels runaway executions, and pauses schedules. |
| FluidGrids Automation Auditor | Reviews workflow designs, trigger configuration, and execution history as read-only evidence, changing nothing. |
Access by resource
Each cell is the level the role holds on that resource type. — means the role has no access to it at all.
| Resource | Automation Owner | Automation Lead | Workflow Designer | Integration Engineer | Run Operator | Automation Auditor |
|---|---|---|---|---|---|---|
ai-prompt | Admin | Admin | Editor | — | — | — |
ai-workflow | Admin | Admin | Editor | — | — | — |
artifact | Admin | Admin | Editor | — | — | — |
chat-message | Admin | Admin | Editor | — | — | — |
chat-session | Admin | Admin | Editor | — | — | — |
dashboard | Viewer | Viewer | Viewer | Viewer | Viewer | Viewer |
data-table | Admin | Admin | Editor | — | Viewer | Viewer |
data-table-row | Admin | Admin | Editor | — | Editor | — |
event-filter | Admin | Admin | Editor | — | Viewer | Viewer |
event-registration | Admin | Admin | Editor | — | Editor | Viewer |
log-stream-destination | Admin | Admin | — | Admin | — | — |
node | Admin | Viewer | Viewer | Admin | Viewer | Viewer |
node-endpoint-config | Admin | Viewer | Viewer | Admin | Viewer | Viewer |
node-installation | Admin | Viewer | Viewer | Admin | Viewer | Viewer |
node-state | Admin | Admin | Editor | Viewer | Editor | Viewer |
operation-config | Admin | Viewer | Viewer | Admin | Viewer | Viewer |
scheduled-job | Admin | Admin | Editor | — | Editor | Viewer |
search | Viewer | Viewer | Viewer | Viewer | Viewer | Viewer |
secrets-provider-config | Admin | Admin | — | Admin | — | — |
submission | Admin | Viewer | — | Admin | — | Viewer |
system-config | Admin | — | — | — | — | — |
tool-approval-request | Admin | Admin | — | — | Editor | — |
usage | Admin | Viewer | — | — | — | Viewer |
webhook-delivery | Admin | Admin | Viewer | — | Editor | Viewer |
workflow | Admin | Admin | Editor | Viewer | Viewer | Viewer |
workflow-run | Admin | Admin | Editor | Viewer | Editor | Viewer |
workflow-static-data | Admin | Admin | Editor | — | Editor | — |
workflow-variable | Admin | Admin | — | Admin | — | — |
What the resource types cover
| Resource | Covers |
|---|---|
workflow, workflow-variable, workflow-static-data | Workflow definitions and their versions, variables, and the data a workflow keeps between runs |
workflow-run, node-state | Runs, and the state of each node in a run (retrying a node) |
event-registration, event-filter, webhook-delivery, scheduled-job | Triggers: webhook registrations and their filters, webhook deliveries, and schedules |
node, node-installation, node-endpoint-config, operation-config, submission | The node catalog, installed store nodes, custom node endpoints, per-operation settings, and node packages submitted for review |
ai-prompt, ai-workflow, chat-session, chat-message, tool-approval-request | The FluidGrids AI assistant, its chats, and approvals for tools it wants to run |
artifact, data-table, data-table-row | Generated artifacts (code, data, documents, images), and data tables with their rows |
log-stream-destination, secrets-provider-config, system-config | Where run logs are streamed, external secrets providers, and module-wide system configuration |
dashboard, search, usage | The dashboard, search, and execution usage |
Credentials (integration connections) and the vault are platform features with their own permissions; see Credentials.
Assigning roles
- Open Permissions in the Workspace Modules group of the sidebar.
- Find the member and add one or more of the FluidGrids roles.
- The change applies to the member's next request. They may need to reload the app to see their new menu.
Workspace membership itself (inviting people, removing them, creating workspaces) is managed under Administration in the Global Modules group, and group membership under Groups.
Choosing roles
| If the person… | Give them |
|---|---|
| Owns FluidGrids in the workspace, including the connector registry and settings | Automation Owner |
| Decides which versions run, and arms triggers and schedules | Automation Lead |
| Builds and tests workflows | Workflow Designer |
| Curates connectors and custom nodes | Integration Engineer |
| Keeps runs healthy: retries, cancels, pauses schedules | Run Operator |
| Reviews designs and execution history without changing anything | Automation Auditor |
Start with the narrowest role that covers the job and add a second role when someone needs more.
When a member is denied
- A screen the member's roles cannot use at all is removed from their sidebar.
- If one widget on a screen needs a permission the member lacks, that widget shows an access message or the toast You don't have permission to do that., and the rest of the screen keeps working.
- API, CLI and SDK calls fail with a
FORBIDDENerror.
To fix it, add the role that grants the level the action needs (see the table above). Do not give someone Automation Owner just to unblock one action.