Roles and Permissions

When you invite team members to your organization or workspace, you'll need to choose what level of access to give them. This guide explains what each permission level allows users to do, helping you understand team roles and what access each permission level provides.

How to Invite Someone to a Workspace

Workspace Permission Levels

When inviting someone to a workspace, you can assign one of three permission levels:

Permission	What They Can Do
Read	View workflows, see execution results, but cannot make any changes
Write	Create and edit workflows, run workflows, manage environment variables
Admin	Everything Write can do, plus invite/remove users and manage workspace settings

What Each Permission Level Can Do

Here's a detailed breakdown of what users can do with each permission level:

Read Permission

Perfect for: Stakeholders, observers, or team members who need visibility but shouldn't make changes

What they can do:

View all workflows in the workspace
See workflow execution results and logs
Browse workflow configurations and settings
View environment variables (but not edit them)

What they cannot do:

Create, edit, or delete workflows
Run or deploy workflows
Change any workspace settings
Invite other users

Write Permission

Perfect for: Developers, content creators, or team members actively working on automation

What they can do:

Everything Read users can do, plus:
Create, edit, and delete workflows
Run and deploy workflows
Add, edit, and delete workspace environment variables
Use all available tools and integrations
Collaborate in real-time on workflow editing

What they cannot do:

Invite or remove users from the workspace
Change workspace settings
Delete the workspace

Admin Permission

Perfect for: Team leads, project managers, or technical leads who need to manage the workspace

What they can do:

Everything Write users can do, plus:
Invite new users to the workspace with any permission level
Remove users from the workspace
Manage workspace settings and integrations
Configure external tool connections
Delete workflows created by other users

What they cannot do:

Delete the workspace (only the workspace owner can do this)
Remove the workspace owner from the workspace

Workspace Owner vs Admin

Every workspace has one Owner (the person who created it) plus any number of Admins.

Workspace Owner

Has all Admin permissions
Can delete the workspace
Cannot be removed from the workspace
Can transfer ownership to another user

Workspace Admin

Can do everything except delete the workspace or remove the owner
Can be removed from the workspace by the owner or other admins

Common Scenarios

Adding a New Developer to Your Team

Organization level: Invite them as an Organization Member
Workspace level: Give them Write permission so they can create and edit workflows

Adding a Project Manager

Organization level: Invite them as an Organization Member
Workspace level: Give them Admin permission so they can manage the team and see everything

Adding a Stakeholder or Client

Organization level: Invite them as an Organization Member
Workspace level: Give them Read permission so they can see progress but not make changes

Adding a Workspace Ops Lead

Organization level: Invite them as an Organization Supervisor
They can create workspaces and manage workspace membership across the organization — without billing access or automatic visibility into workspace content

Environment Variables

Users can create two types of environment variables:

Personal Environment Variables

Only visible to the individual user
Available in all workflows they run
Managed in Settings, then go to Secrets

Workspace Environment Variables

Read permission: Can see variable names and values
Write/Admin permission: Can add, edit, and delete variables
Available to all workspace members
If a personal variable has the same name as a workspace variable, the personal one takes priority

Best Practices

Start with Minimal Permissions

Give users the lowest permission level they need to do their job. You can always increase permissions later.

Use Organization Structure Wisely

Make trusted team leads Organization Admins
Use Organization Supervisor for people who manage workspace assignments but shouldn't touch billing or organization settings
Most team members should be Organization Members
Reserve workspace Admin permissions for people who need to manage users

Review Permissions Regularly

Periodically review who has access to what, especially when team members change roles or leave the company.

Environment Variable Security

Use personal environment variables for sensitive API keys
Use workspace environment variables for shared configuration
Regularly audit who has access to sensitive variables

Personal Organization

Every SteelEngine account has at least one organization. When you sign up, SteelEngine automatically creates a personal organization for you, with a default workspace inside it, and you land on your organization dashboard at /<orgSlug> after first sign-in. No setup step asks you to name it — the slug is generated from a curated word-pair list (mild-owl, prime-horse, etc.).

You're the Organization Admin of your personal org. It behaves identically to a team-created org:

You can invite teammates to it
You can rename it (which also updates the URL slug)
You can upgrade it from Free to Pro or Max
You can create additional workspaces inside it

You cannot delete the personal org if it's your only organization — every account must belong to at least one. To leave a personal org behind, join or create another organization first and ignore the personal one going forward.

You can also join other organizations without leaving your personal org. Each org keeps its own members, roles, billing limits, workspaces, credentials, and access-control settings.

For the full URL anatomy, slug rules, and switching between organizations, see Organizations and Workspaces.

Organization Roles

When inviting someone to your organization, you can assign one of three roles: Admin, Supervisor, or Member.

Capability	Admin	Supervisor	Member
Manage organization members and invitations	✓	—	—
Manage billing, subscription, and per-workspace usage limits	✓	—	—
Manage SSO, branding, permission groups, and model availability	✓	—	—
Create workspaces	✓	✓	✓
Manage workspace membership and assign workspace roles	✓	✓	—
Automatic Admin access to every workspace	✓	—	—
Workspace content access	All workspaces	Only where explicitly granted	Only where explicitly granted

Organization Admin

Full organization authority.

Invite and remove organization members
Manage billing and subscription settings, including per-workspace usage limits
Manage SSO, branding, permission groups, and organization-wide model availability
Implicit Admin access to every workspace in the organization — no workspace invitation needed

Organization Supervisor

An operational tier for people who run workspaces without organization-wide authority.

Create workspaces, and manage which members belong to which workspace at which permission level
No automatic access to workspace content — a supervisor sees inside a workspace only when explicitly granted a workspace permission
Cannot manage organization members, billing, or organization settings

Organization Member

The default role.

Works in the workspaces they've been explicitly granted access to
Can create new workspaces — they become that workspace's owner, with Admin permission on it
Cannot invite people to the organization or manage organization settings

The legacy Owner organization role is treated as Admin — existing owners were migrated automatically.

Common Questions

Organization roles (Admin, Supervisor, or Member) control who can manage the organization itself — inviting people, handling billing, and managing workspace membership. Workspace permissions (Read, Write, Admin) control what a user can do within a specific workspace, such as viewing, editing, or managing workflows. A user needs a workspace permission to work inside a workspace — granted explicitly, or implicitly for organization Admins, who get Admin access to every workspace.

Admins have full organization authority: members, billing, settings, and automatic Admin access to every workspace. Supervisors handle day-to-day workspace operations — creating workspaces and deciding who belongs to which workspace at which permission level — but cannot manage billing or organization settings, and they don't see workspace content unless explicitly granted access.

When you sign up, SteelEngine auto-creates a personal organization for you with a generated word-pair slug (e.g. mild-owl) and a default workspace inside it. You land on its dashboard after first sign-in. You're the Admin of your personal org and it behaves identically to a team-created org — you can invite members, upgrade it, rename it, or create more workspaces inside it. You cannot delete it if it's your only org, but you can create a fresh organization for your team and stop using the personal one. See the Organizations and Workspaces guide for details.

Yes. Organization admins can create permission groups with fine-grained controls, including restricting allowed integrations and allowed model providers to specific lists. You can also disable access to MCP tools, custom tools, skills, and various platform features like the knowledge base, API keys, or Copilot on a per-group basis.

The personal environment variable takes priority. When a workflow runs, if both a personal and workspace variable share the same name, the personal value is used. This allows individual users to override shared workspace configuration when needed.

No. The workspace owner cannot be removed from the workspace by anyone. Only the workspace owner can delete the workspace or transfer ownership to another user. Admins can do everything else, including inviting and removing other users and managing workspace settings.

Permission groups are an advanced access control feature that lets organization admins define granular restrictions beyond the standard Read/Write/Admin roles. A permission group can hide UI sections (like trace spans, knowledge base, API keys, or deployment options), disable features (MCP tools, custom tools, skills, invitations), and restrict which integrations and model providers members can access. Members can be assigned to groups, and new members can be auto-added.

Start with the lowest permission level they need. Invite them to the organization as a Member, then add them to the relevant workspace with Read permission if they only need visibility, Write if they need to create and run workflows, or Admin if they need to manage the workspace and its users. You can always increase permissions later.

Roles and Permissions

Common Questions

On this page