Skip to main content
Documentation Navigation:
This page provides comprehensive permission matrices for all predefined roles in FlowX. Use this as a reference when planning access control strategies.

How to use this reference

1

Identify the role level

Determine whether you need organization, workspace, or project-level access
2

Find the appropriate role

Review the role descriptions and select the one matching your requirements
3

Verify permissions

Check the detailed permission matrix to ensure it meets your needs
4

Implement access control

Assign roles according to the principle of least privilege

Permission legend

The permission matrices use the following symbols:

Organization level permissions

Organization admin permission matrix

The org_admin role has the following permissions:

Organization Admin Role Constraints

Management Rules:
  • Cannot be edited, duplicated, or deleted
  • Can only be assigned in the Organization admin space
  • Hidden from workspace role lists
  • Cannot be assigned at workspace level
  • Must be assigned to at least one user during initial setup

Organization owner permission matrix

The Organization Owner is a predefined organization-level role focused on account, dashboard, usage, and end-user (runtime) administration. It is not interchangeable with Organization Admin: managing Designer users, workspaces, and Designer roles, including promoting another user to organization admin, requires the Organization Admin role.

Organization Owner Role Constraints

Management Rules:
  • Predefined organization-level role
  • Focused on account and end-user administration, not Designer platform administration
  • For Designer user, workspace, and role management, use the Organization Admin role

Workspace level permissions

Workspace admin permission matrix

The workspace_admin role has the following permissions:

Workspace Admin Role Constraints

Management Rules:
  • Cannot be edited or deleted (predefined role)
  • Listed in workspace role management interfaces
  • Can be assigned to users/groups within the workspace
  • Can be assigned when granting access to workspace
  • Cannot manage organization-wide settings

Workspace user permission matrix

The workspace_user role has the following permissions:

Workspace User Role Constraints

Management Rules:
  • Cannot be edited or deleted (predefined role)
  • Can be duplicated to create custom variations (future feature)
  • Default role for most workspace members
  • Can be assigned when granting access to workspace
  • Limited administrative capabilities

Theme editor permission matrix

The theme_editor role extends workspace_user with additional permissions:

Theme Editor Role Constraints

Management Rules:
  • Same base constraints as workspace_user
  • Cannot be edited or deleted (predefined role)
  • Can be duplicated to create custom variations (future feature)
  • Specialized role for UI/UX designers and brand managers

Workspace runtime editor permission matrix

The workspace_runtime_editor role extends workspace_user with additional permissions:

Runtime Editor Role Constraints

Management Rules:
  • Same base constraints as workspace_user
  • Cannot be edited or deleted (predefined role)
  • Can be duplicated to create custom variations (future feature)
  • Specialized role for DevOps and runtime environment administrators

Workspace operations editor permission matrix

The workspace_operations_editor role extends workspace_user with additional permissions:

Operations Editor Role Constraints

Management Rules:
  • Same base constraints as workspace_user
  • Cannot be edited or deleted (predefined role)
  • Can be duplicated to create custom variations (future feature)
  • Specialized role for operations management (process migration & token operations)

Project level permissions

Project owner permission matrix

The project_owner role has the following permissions:

Project Owner Role Constraints

Management Rules:
  • System-managed role, cannot be edited or deleted
  • Automatically assigned to user who creates project
  • Hidden from role selection interfaces
  • Cannot be manually assigned through UI
  • Permanent assignment for project lifecycle
  • Can be transferred to another user (ownership transfer)

Project editor permission matrix

The project_editor role has the following permissions:

Project Editor Role Constraints

Management Rules:
  • Cannot be edited or deleted (predefined role)
  • Can be duplicated to create custom variations (future feature)
  • Can be assigned to users/groups when granting project access
  • Standard role for project team members
  • No ownership rights (cannot grant/revoke project access)

Project viewer permission matrix

The project_viewer role has the following permissions:

Project Viewer Role Constraints

Management Rules:
  • Cannot be edited or deleted (predefined role)
  • Can be duplicated to create custom variations (future feature)
  • Can be assigned to users/groups when granting project access
  • Safe role for stakeholders needing visibility
  • No modification capabilities
  • Can test processes and workflows through the interface

Role comparison matrix

Quick reference: All roles compared

* Workspace-level roles can only edit project resources for projects they have been explicitly granted access to. Having a workspace role does not automatically grant access to all projects.

Detailed capability breakdown

Organization-level capabilities

Workspace-level capabilities

Project-level capabilities

Permission inheritance patterns

Workspace to project inheritance

Understanding how workspace roles interact with project roles is critical for proper access management.
Key Principles:
  1. Workspace roles DO NOT automatically grant project access
    • A user with workspace_admin still needs explicit project role to access specific projects
    • Exception: workspace_admin can grant themselves access via admin privileges
    • Exception: Users with projects_admin permission (included in workspace_admin) automatically receive project_owner capabilities on all projects in that workspace
  2. Project roles are additive to workspace permissions
    • User can have workspace_user + project_editor on specific project
    • Permissions combine (union), not override
  3. Most permissive permission wins
    • If user has project_viewer via one group and project_editor via another, they get editor access
  4. Multiple workspace roles can be assigned simultaneously
    • Users can combine workspace roles for specialized access patterns
    • Example: A user can be both theme_editor and runtime_editor in the same workspace
    • Permissions from all assigned roles combine (union), enabling flexible role compositions
Examples:

Group-based permission inheritance

Group Membership Resolution:
  1. User’s permissions = Union of (individual permissions + all group permissions)
  2. More permissive permission always wins
  3. No negative permissions (cannot restrict via groups)
Example:

Special permission features

Read-only view behavior

Read-Only Mode Characteristics

When a user has read-only permissions (e.g., project_viewer role), they experience:Visible but Disabled:
  • All configuration elements visible but not editable
  • Save buttons hidden or disabled
  • Edit controls grayed out or absent
  • Delete actions not available
Available Functionality:
  • Export operations (where applicable)
  • Audit log access
  • Usage overview and tracking
  • Copy operations to other projects/libraries (for reference)
  • Process and workflow testing through interface
UI Indicators:
  • β€œView” label instead of β€œConfigure” in contextual menus
  • Read-only badges or indicators
  • No modification prompts or warnings

Bulk permission selection

When configuring custom roles (future feature), bulk selection simplifies permission assignment.
Bulk Selection Categories: How Bulk Selection Works:
  1. Select permission category (e.g., β€œWorkspace Entities”)
  2. Choose operation level (e.g., β€œRead”)
  3. All resources in category receive selected permission
  4. Individual permissions can be adjusted afterward
  5. Saves time when creating roles with consistent patterns

Permission dependencies

Auto-Included Permissions

Certain permissions automatically include others to ensure functionality:Workspace Level:
  • Any workspace permission β†’ automatically includes workspace_read
  • Any workspace edit permission β†’ should include workspace_edit
Project Level:
  • Any project permission β†’ automatically includes project_read (backend)
  • Note: project_read not displayed in UI but sent to backend
Rationale: Read permissions provide the foundation for all other operations. Without read access, users cannot see resources to edit, create, or delete them.

Workspaces Access Rights

Overview of FlowX workspace access rights and role hierarchy

Permission Reference Guide

Technical implementation details, UI mappings, and naming conventions

Role Selection Guide

Practical guidance for choosing and assigning appropriate roles

Access Management Overview

Overview of authentication and authorization in FlowX

Configuring IAM Solution

Setting up identity and access management with Keycloak

Workspaces

Understanding workspaces and organizing projects
Last modified on June 30, 2026