Reference

Roles and permissions

Access in Sim is organized into three nested levels — your organization, the workspaces inside it, and the credentials (connected accounts and secrets) inside those. Each level has its own roles, and roles inherit downward: an admin at one level is automatically an admin at the level below. Inheritance only ever adds access — it never takes access away from someone who already has it.

How roles inherit

Each level has its own set of roles:

LevelRoles
OrganizationOwner, Admin, Member
WorkspaceRead, Write, Admin
Credentials (shared connections and secrets)Member, Admin

Higher roles flow down automatically:

  • An organization Owner or Admin is automatically an Admin of every workspace in the organization — no per-workspace invite required.
  • A workspace Admin is automatically an Admin of every shared credential in that workspace — OAuth connections, service accounts, and workspace secrets.

Put together, an organization Owner or Admin can administer every workspace and every shared credential in the organization, top to bottom.

Inherited roles are automatic and locked. In member lists they show greyed out with a short tooltip saying where the role comes from (for example, "Organization admins are automatically workspace admins"), and they can't be lowered there — you change them at the level they come from.

Personal secrets are the one exception. A user's personal environment variables stay private to them and are never shared or inherited — not by workspace Admins, not by organization Owners or Admins, not by anyone.

Workspaces and Organizations

Sim has two kinds of workspaces:

  • Personal workspaces live under your individual account. The number you can create depends on your plan.
  • Shared (organization) workspaces live under an organization and are available on Team and Enterprise plans. Any organization Owner or Admin can create them. When you invite someone to a shared workspace you choose their Membership: Member or Admin makes them an internal member of the organization — they use a seat, and their own workspaces move in with them (see Joining an organization) — while External gives them access to the selected workspaces only. Invitees who already belong to another organization always become external, because a Sim account belongs to at most one organization.

Workspace Limits by Plan

PlanPersonal WorkspacesShared Workspaces
Free1
ProUp to 3
MaxUp to 10
Team / EnterpriseUnlimited (Owners and Admins)

On Team and Enterprise plans, every workspace you create belongs to the organization. Organization Owners and Admins can create unlimited shared workspaces; organization Members cannot create workspaces. Personal workspaces you owned before joining move into the organization when you accept the invite — see Joining an organization. Enterprise invites require an available seat at invite time; on Team plans, a seat is added automatically when the invitee accepts.

When a Team or Enterprise subscription is cancelled or downgraded, existing shared workspaces stay accessible to current members. New invitations are blocked until the organization is upgraded again.

How to Invite Someone to a Workspace

One invite covers everything you give a person at once: enter their emails, select one or more workspaces, set the workspace access level, and choose their Membership. The same dialog opens from the workspace header and from organization settings.

Invites to the same person add up rather than stacking. If you invite someone to another workspace while their first invite is still pending, the new workspace is added to that invitation — they get one link that grants everything, and accept once.

Because one pending invite can span several workspaces, revoking is scoped to where you do it. Revoking from a workspace's Teammates list withdraws that workspace's access only and leaves the rest of the invitation pending; the invitation is cancelled outright when you remove its last workspace. To cancel the whole thing at once, revoke it from organization settings — that needs organization admin, or admin on every workspace the invite covers.

Workspace Permission Levels

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

PermissionWhat They Can Do
ReadView workflows, see execution results, but cannot make any changes
WriteCreate and edit workflows, run workflows, manage environment variables
AdminEverything Write can do, plus invite/remove users and manage workspace settings

Internal Members vs External Workspace Members

Workspace permissions are separate from organization membership:

  • Internal organization members belong to your organization, appear in the organization roster, and count toward your seat total. Invite new teammates this way when they should be part of your company or team in Sim.
  • External workspace members have access only to the workspaces they are invited to. They are not part of your organization: they do not count toward your seats, their own workspaces stay theirs, and they appear in your roster with an External label so admins can always see and revoke their access. Use external access for clients, partners, and contractors.

You pick between the two with the Membership option when sending an invite. Three rules apply:

  • External is only available for people already on a paid Sim plan — their own Pro or Max subscription, or membership in another organization that seats them. External collaborators do not use one of your seats, so they have to be paying for Sim somewhere else. Inviting someone on the free plan as External is rejected with a message telling you to invite them as a Member or Admin instead, which adds a seat.
  • Invitees who already belong to another organization are always external, whatever you pick, because an account belongs to at most one organization.
  • Inviting someone as a Member to the organization itself always includes access to at least one workspace, so every new member has somewhere to land.

Invitees see what they are agreeing to before they accept. The accept screen names every workspace they are being given, says whether they are joining as a member, an admin, or an external collaborator, says whether that uses one of your seats, and names any of their own workspaces that will move into the organization.

External workspace members still receive a workspace permission level — Read, Write, or Admin — and that permission controls what they can do inside the workspace.

Joining an organization

Accepting an invite that makes you an internal member does more than grant access — it brings your work under the organization:

  • Your workspaces move with you. Every personal workspace you own, archived ones included, becomes an organization workspace. The accept screen names the workspaces that will move before you accept.
  • You keep Admin on them. You remain their administrator; organization Owners and Admins also gain Admin access through the normal role inheritance, and usage in those workspaces is billed to the organization from then on.
  • Your collaborators are not pulled in. Anyone you had shared those workspaces with keeps their access as an external member — they never join the organization or consume a seat as a side effect of your joining.
  • The workspaces stay if you leave. If you later leave or are removed from the organization, workspaces you brought in remain with the organization.

Accepting an external invite changes none of this: you get access to the invited workspace only, and everything you own stays yours.

What Each Permission Level Can Do

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

Read Permission

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

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

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
  • Administer every shared credential in the workspace (OAuth connections, service accounts, and workspace secrets)
  • Delete workflows created by other users
  • Delete the workspace

What they cannot do:

  • Change a role that's inherited from a higher level — an organization admin's workspace role, or the owner's, is locked and managed where it comes from

Workspace Owner

Every workspace has one Owner — usually the person who created it. The Owner is simply an Admin whose role is fixed: in the member list it shows as a locked Admin (tooltip "Workspace owner"), so it can't be lowered. An Owner has no abilities a regular Admin lacks.

Any Admin — whether invited directly or an admin by way of their organization role — can manage members and settings and delete the workspace. On a shared workspace an Admin can also remove the Owner; ownership then passes to the organization's owner, so the workspace always has one. (The organization's owner is the one account that can't be removed this way — they're the final fallback.) On your personal workspace you are the Owner and can't be removed.


Common Scenarios

Adding a New Developer to Your Team

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

Adding a Project Manager

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

Adding a Stakeholder or Client

  1. Membership: If they should not join your organization, set Membership to External — this needs them to already be on a paid Sim plan, since external collaborators do not use one of your seats
  2. Workspace level: Give them Read permission so they can see progress but not make changes

Environment Variables

Users can create two types of environment variables:

Personal Environment Variables

  • Only visible to the individual user, and never shared or inherited — not even by workspace or organization admins
  • Available in all workflows they run
  • Managed in Settings, then go to Secrets

Workspace Environment Variables

  • Read: see variable names (the values stay hidden unless you're an admin of that secret)
  • Write: add new variables, and edit or delete ones you created
  • Admin: add, edit, delete, and view the values of any workspace variable
  • Workspace variables are a kind of workspace credential, so they follow the Credential Access rules below — workspace Admins are admins of all of them
  • Available to all workspace members. If a workspace variable and a personal variable share the same name, the workspace value wins when a workflow runs

Credential Access

Workspace credentials — OAuth connections, service accounts, and workspace environment variables — have two roles of their own:

  • Credential Member: can use the credential in workflows.
  • Credential Admin: can use it and also edit, delete, and share it.

These roles follow your workspace role:

  • Workspace Admins are automatically Credential Admins of every shared credential in the workspace (OAuth connections, service accounts, and workspace environment variables). Because organization Owners and Admins are workspace Admins everywhere, they are Credential Admins too. These automatic roles are fixed — they show greyed out with a tooltip in the credential's member list and cannot be changed.
  • Read and Write members are Credential Members by default — they can use shared credentials but cannot edit, delete, or share them unless someone makes them a Credential Admin (you are always an admin of credentials you create).
  • Personal environment variables are the exception: they stay private to their owner and are never shared with workspace admins.

A Credential Admin can both use and manage a credential, so a workspace Admin can run workflows that use any shared OAuth connection in the workspace — including one another member added.


Organization Roles

An organization has three roles: Owner, Admin, and Member.

Organization Owner

What they can do:

  • Everything an Admin can do
  • Transfer organization ownership to another user
  • Only one Owner exists per organization

Organization Admin

What they can do:

  • Invite and remove team members from the organization
  • Create new shared workspaces under the organization
  • Manage billing, seat count, and subscription settings
  • Access every shared workspace in the organization as a workspace Admin automatically (no per-workspace invite), including administering the credentials inside them
  • Promote members to Admin or demote Admins to Member

Owners and Admins have the same day-to-day permissions. The only action reserved for the Owner is transferring ownership.

Organization Member

What they can do:

  • Access shared workspaces they've been specifically invited to
  • View the list of organization members
  • Cannot invite new people, create shared workspaces, or manage organization settings

Common Questions

Organization roles (Owner, Admin, or Member) control who can manage the organization itself, including inviting people, creating shared workspaces, and handling billing. Workspace permissions (Read, Write, Admin) control what a user can do within a specific workspace, such as viewing, editing, or managing workflows. Internal members need both an organization role and a workspace permission to work within a shared workspace. External workspace members do not have an organization role in your org; they only have workspace-level access.
They move into the organization when you accept the invite — archived workspaces included. The accept screen names the workspaces that will move before you accept. You stay their Admin, organization Owners and Admins gain Admin access through role inheritance, and usage in them is billed to the organization from then on. People you had shared them with keep access as external members. If you later leave the organization, those workspaces stay with it. Accepting an external invite never moves anything — everything you own stays yours.
Their workspace access is revoked and workflows they created are reassigned so deployed automations keep running. Credentials backed by their personal identity — OAuth connections and personal environment keys they own — stop working until another member reconnects them; the removal dialog names the affected credentials before you confirm. Workspaces they brought into the organization stay with the organization.
Existing shared workspaces remain accessible to current members, but new invitations are disabled until you upgrade back to a Team or Enterprise plan. No workspaces or members are deleted — the organization is simply dormant until billing is re-enabled.
Yes, on Enterprise-entitled organizations. Any organization owner or admin 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. Permission groups are scoped to the organization and can govern either all workspaces or a specific subset — a user can belong to multiple groups but is governed by exactly one group in any given workspace.
The workspace variable wins. When a workflow runs, the resolver checks workspace variables first and falls back to a personal variable only when no workspace variable shares that name. This keeps shared, team-managed values authoritative in production workflows.
On a shared (organization) workspace, yes — any Admin can remove the workspace Owner, and ownership passes to the organization's owner so the workspace always has one. The organization's owner is the single account that can't be removed this way, since they're the final fallback. On your personal workspace you are the Owner and can't remove yourself. The Owner is not a higher permission tier than Admin: every Admin — including those who inherit the role from their organization — can manage members and settings and delete the workspace.
Workspace Admins are automatically Credential Admins of the workspace's shared credentials — OAuth connections, service accounts, and workspace environment variables — so they can use, edit, delete, and share them, and run workflows that rely on them. Organization Owners and Admins get this too because they are workspace Admins everywhere. Read and Write members get use-only access to shared credentials unless they are explicitly made a Credential Admin. Personal environment variables are never shared; they stay private to their owner.
Permission groups are an Enterprise access control feature that lets organization owners and admins define granular restrictions beyond the standard Read/Write/Admin roles. The organization's default group is org-wide; every other group targets specific workspaces and, by default, governs all members of those workspaces (including external members) — add members to restrict it to specific people. A user is governed by one group per workspace: a group they're an explicit member of takes precedence over an all-members group (one with no members) on that workspace, which takes precedence over the organization's default group. 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 its members can access. Only one group per organization can be the default; it ignores members and governs everyone not covered by a workspace group, including external members. Restrictions are enforced based on the organization that owns the workflow's workspace, not on which workspace you're currently viewing.
Start with the lowest permission level they need. Invite them with Read workspace access 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, and leave Membership on Member. For clients, partners, and contractors, choose External so they collaborate without joining your organization or using a seat — this requires them to already be on a paid Sim plan, either their own Pro or Max subscription or another organization that seats them.

On this page