Team RBAC and Workflow Permissions | FluidGrids Use Cases

Enterprise automation fails its access review long before it fails technically. "Who can change this workflow? Who can run it? Who approved that?" need structural answers, and FluidGrids inherits them from the Burdenoff platform rather than bolting them on.

All 26 workflow and run operations carry a role-based permission check — granular actions (read, create, update, delete, execute) crossed with resources (workflow, workflow-run, node-state, admin), scoped to the workspace. Enforcement happens at the platform API layer, the single point every request passes through, whether it comes from the first-party app, the embedded SDK, or a script.

That granularity maps directly onto separation of duties. A Designer role gets workflow read, create, and update — analysts draft and iterate freely, but triggering a run is denied. A Lead role adds execute and the lifecycle operations, so activation is a deliberate, attributable act by someone accountable. An Auditor role is read-only across workflows and run history: full visibility, zero blast radius. Roles and assignments are managed in the platform RBAC surface FluidGrids shares with every other module.

Above the workspaces sits a separate operational plane, restricted to platform administrators: active workflows across the fleet, a recent-errors feed filterable by severity and node type, node usage statistics to find resource hogs, node-level logs, and the ability to terminate a runaway run. A workspace owner doesn't get this view by being an owner — operating the platform is its own privilege.

The quiet win is that none of this was retrofitted. Multi-tenancy, workspace isolation, audit, and permission checks were the substrate FluidGrids was built on — so the access review meets the same model on workflow one as on workflow one thousand.