Permission groups restrict what people can use in an organization's workspaces. Set a provider or block allowlist, deny individual models or tool operations, or limit platform actions such as exports and deployments. Workspace membership and roles still determine which resources a person can access; a group does not grant access.
Organization owners and admins manage groups under Settings → Organization → Permission groups. Billing-enabled deployments require Enterprise. Billing-disabled deployments use the feature configuration described under Self-hosted setup. Workspaces without an organization have no permission groups.
Create and configure a group
- Open Settings → Organization → Permission groups and click Create group.
- Enter a name and optional description. Select at least one workspace, or make the group the Default group for the organization.
- Open the group's row. Configure its General, Model Providers, Blocks, and Platform tabs.
- Click Save to save its name, description, and permission configuration.
Choose an access state in the provider, block, and platform permission lists:
Use Unavailable for software your organization has not procured. Existing groups retain their permissions and request behavior until you change them. Project Issues keeps its separate checklist: checked projects are restricted.
Search and the state filter narrow each list. Set shown to… changes only the visible, editable rows and offers choices supported by all of them. Changes remain a draft until Save; Discard restores the saved configuration.
A restricted parent also restricts its children. Expand a provider, integration, or platform feature to inspect its models, tools, connectors, or authentication modes. Allow the parent before editing its children. Child choices are preserved when a parent changes. An unavailable child stays unavailable even if its parent allows requests. Requests cannot bypass an unavailable parent.
The info icon beside an item explains its restriction and, for inherited choices, names the parent to change. Hover or focus the icon to read the help, or click or tap to keep it open. Press Escape or click outside to dismiss it.
These choices configure the group's policy, independently of the deployment's current availability. Allowed and Can request cannot enable a deployment-disabled feature or bypass a workspace role. Members only discover and request items available to their deployment and role. Custom blocks, private dynamically discovered models, and other items outside the public request catalog do not offer Can request.
General
The General tab sets the name, description, workspaces, members, and default-group status. Sim selects a single governing group for each person and workspace:
- A non-default group targeting that workspace with the person as an explicit member.
- Otherwise, a non-default group targeting that workspace in inheritance membership mode with no named members. It governs all workspace members, including external members.
- Otherwise, the organization's default group, if configured.
- Otherwise, no permission-group restrictions.
The default is a fallback. Its restrictions are not combined with a selected workspace group. Only one group can be the organization default; it applies across the organization's workspaces and ignores a named-member list.
An ordinary workspace group starts by governing all members of its selected workspaces. Adding named members narrows it to those people. Removing its last member can make it govern everyone again. SCIM explicit-membership groups behave differently: an empty explicit group governs nobody. See SCIM provisioning.
Assignment checks allow at most one all-members group per workspace and at most one explicit group per person on a shared workspace. Conflicting individual assignments are rejected; conflicting people in bulk additions are skipped. Scope changes or removing the last inheritance-mode member can also be rejected if they would create a conflict. Sim does not silently move memberships between groups.
A non-default group needs a workspace when created, but you can later remove all its workspaces. It then governs nobody until you add a workspace. External workspace members cannot be selected as named organization members; the workspace's all-members group or organization default can still govern them.
Model Providers
All providers are allowed by default. Select a subset to allow only those providers. Expand a provider to deny individual models while leaving its other models available.
The Agent default chooses the initial model for new Agent blocks. Choose an allowed model, or Platform default to use Sim's default. This setting does not itself restrict models or rewrite existing blocks.
Blocks
Core Blocks contains blocks such as Agent, API, and Function; Integrations and Triggers contains integration blocks. All are allowed by default. Select a subset to restrict block types, then expand an integration to deny individual operations—for example, allow reads while refusing deletes.
The start_trigger entry block is always allowed. Existing workflows are not rewritten when a restriction changes. A run fails if it reaches a blocked type, provider, model, or tool operation.
Platform
Most platform restrictions refuse the protected operation at the server as well as limiting its UI. Trace Spans and Execution Cost instead control which fields an otherwise authorized log read or export returns.
Additional lists narrow selected capabilities:
- Knowledge Base has a connector allowlist. Leave it unrestricted to allow all connectors, or select permitted sources.
- Public Sharing has an auth-mode allowlist: Anyone with link, Password, Email, and SSO.
- Chat Deployment has an auth-mode allowlist: Public, Password, Email, and SSO.
- Project Issues restricts issue access for the checked projects. Governed teammates must have workspace access to every active environment in a selected project.
Restricting Tool Auto-Approval prevents remembering approval for future calls. It does not undo approval of the current call or force confirmation for tools that do not require it. Future calls that require confirmation prompt again.
Organization-level permissions
Workspace Creation and Member Directory read only the organization default, because those actions have no workspace scope. Other groups show them as inactive with an Organization tag, and Set shown to… skips them. A newly created workspace uses the organization default until you add it to a workspace group.
Integrations, API Keys, Invitations, Personal API Keys, CLI Access, and OAuth App Access use the selected workspace group for workspace operations. Account-level operations use the organization default: minting a personal key, sending organization invitations, approving CLI login, authorizing or refreshing OAuth, and account-level billing or audit reads.
How enforcement applies
A human's governing group applies to session, personal API-key, OAuth, and delegated operations. Workflow restrictions are checked during execution, including deployments invoked by API, schedule, or webhook, using the operation's authorized identity. They do not replace workspace roles, credential access, or OAuth scopes.
A workspace API key acts as the workspace. It has workspace-role and operation policies but no human user's permission group; Sim does not apply the key creator's group as a substitute. A human's permission to create or manage that key is still governed.
Chat filters restricted blocks from its available block catalog. Generated steps can still reference a restricted MCP tool, custom tool, or skill; execution rejects the restricted operation when reached. After changing a group, verify both the person's available UI and a representative authorized run. For an existing workflow that fails, remove the restricted item or change the governing policy.
Access requests
Members can request items marked Can request from a locked feature or Settings → Requests → Browse access. Administrators review the request and its impact before approving. Approval updates the governing permission group, so it affects everyone governed by that group; it is not a personal exception.
An organization administrator can pause requests in Settings → Requests → Review requests. Requestable features remain discoverable, but new requests and approvals are disabled. The group's saved choices, request history, and cancellation remain available. Changing an item to Unavailable also prevents approval of an older pending request for that item or a dependent child. Administrators can still decline those requests.
The API keeps the existing access fields. The optional deniedAccessRequests list stores canonical target keys such as integration:salesforce and feature:hideTablesTab. An absent or empty list preserves the previous request behavior. Partial configuration updates retain unspecified choices. Request approval never changes this list. Member credit-limit requests remain separate from permission-group access settings.
Self-hosted setup
On billing-disabled deployments, enable permission groups through the enterprise feature configuration or explicitly set:
The enterprise master configuration can enable the feature; an explicit feature value takes precedence. Billing-enabled self-hosted deployments still require Enterprise. See self-hosted enterprise setup.
ALLOWED_INTEGRATIONS adds an instance-wide block allowlist. A block must satisfy both that list and the applicable group policy; start_trigger remains available.