@@ -13,7 +13,7 @@ Access Control lets organization admins define permission groups that restrict w
 
 ## How it works
 
-Access control is built around **permission groups**. Each group belongs to a specific organization and has a name, an optional description, a **workspace scope**, an optional **member** list, and a configuration that defines what its members can and cannot do. The organization's single **default group** is org-wide; every other group targets a **specific set of workspaces**. A non-default group with **no members** governs **all members** of its workspaces (including external members); adding members narrows it to only those people. Personal or grandfathered workspaces that do not belong to an organization have no permission groups.
+Each group belongs to a specific organization and has a name, an optional description, a **workspace scope**, an optional **member** list, and a configuration that defines what its members can and cannot do. Personal or grandfathered workspaces that do not belong to an organization have no permission groups.
 
 Sim resolves the governing group for a user in a workspace deterministically:
 
@@ -59,7 +59,9 @@ A workspace-scoped group with **no members** applies to everyone in its workspac
 
 Controls which AI model providers members of this group can use.
 
-<Image src="/static/enterprise/access-control-model-providers.png" alt="Model Providers tab showing a grid of AI providers including Ollama, vLLM, OpenAI, Anthropic, Google, Azure OpenAI, and others with checkboxes to allow or restrict access" width={900} height={430} /> The list shows all providers available in Sim.
+<Image src="/static/enterprise/access-control-model-providers.png" alt="Model Providers tab showing a grid of AI providers including Ollama, vLLM, OpenAI, Anthropic, Google, Azure OpenAI, and others with checkboxes to allow or restrict access" width={900} height={430} />
+
+The list shows all providers available in Sim.
 
 - **All checked (default):** All providers are allowed.
 - **Subset checked:** Only the selected providers are allowed. Any workflow block or agent using a provider not on the list will fail at execution time.
@@ -70,7 +72,9 @@ Expand a provider row to reach its **model denylist**. Clearing individual model
 
 Controls which workflow blocks members can place and execute.
 
-<Image src="/static/enterprise/access-control-blocks.png" alt="Blocks tab showing Core Blocks (Agent, API, Condition, Function, Knowledge, etc.) and Tools (integrations like 1Password, Ahrefs, Airtable, and more) with checkboxes to allow or restrict each" width={900} height={634} /> Blocks are split into two sections: **Core Blocks** (Agent, API, Condition, Function, etc.) and **Tools** (all integration blocks).
+<Image src="/static/enterprise/access-control-blocks.png" alt="Blocks tab showing Core Blocks (Agent, API, Condition, Function, Knowledge, etc.) and Tools (integrations like 1Password, Ahrefs, Airtable, and more) with checkboxes to allow or restrict each" width={900} height={634} />
+
+Blocks are split into two sections: **Core Blocks** (Agent, API, Condition, Function, etc.) and **Tools** (all integration blocks).
 
 - **All checked (default):** All blocks are allowed.
 - **Subset checked:** Only the selected blocks are allowed. Workflows that already contain a disallowed block will fail when run — they are not automatically modified.
@@ -83,7 +87,7 @@ Expand an integration block to reach its **tool denylist**. Clearing individual
 
 #### Platform
 
-Controls the modules, actions, and credentials available to group members. Every row refuses at the API, not only in the UI — clearing a box revokes the access, it does not merely hide a tab.
+Controls the modules, actions, and credentials available to group members. Every row refuses at the API, not only in the UI — clearing a box revokes the access; it does not merely hide a tab.
 
 <Image src="/static/enterprise/access-control-platform.png" alt="Platform tab showing feature toggles grouped by category" width={900} height={566} />
 
@@ -141,7 +145,7 @@ The **Chat Deployment** row also carries an **auth-mode allowlist** — *Auth mo
 | MCP Tools | Blocks agents from calling MCP tools. |
 | Custom Tools | Blocks agents from calling user-defined custom tools. |
 | Skills | Blocks agents from loading skills. |
-| Tool Auto-Approval | Prevents silencing a tool confirmation, so every call is confirmed again. |
+| Tool Auto-Approval | Prevents auto-approving tool calls, so every call must be confirmed. |
 
 **Logs**
 
@@ -156,7 +160,7 @@ The **Chat Deployment** row also carries an **auth-mode allowlist** — *Auth mo
 | Feature | What clearing it withholds |
 |---------|---------------------------|
 | Invitations | Prevents inviting anyone to a workspace or to the organization. |
-| Workspace Creation | Prevents creating new workspaces, which no existing group would govern. |
+| Workspace Creation | Prevents creating new workspaces. A new workspace falls outside every existing group's scope. |
 | Member Directory | Withholds the member directory. Members cannot see the names or email addresses of other members. |
 
 **Credentials & Access**
@@ -174,12 +178,10 @@ The **Chat Deployment** row also carries an **auth-mode allowlist** — *Auth mo
 
 Two rows — **Workspace Creation** and **Member Directory** — are read only from the organization's **default group**, because the act they govern names no workspace. On any other group the editor renders them inert, tags them **Organization**, and skips them in **Select All**. Set them on the default group.
 
-Five more rows — **Integrations**, **API Keys**, **Invitations**, **Personal API Keys**, and **CLI Access** — apply on the group in front of you for anything scoped to one of its workspaces, but fall back to the default group for the account-level path of the same action (minting a personal key, an organization-wide invitation, an account-level CLI login). To close one of these completely, set it on the default group as well.
+Five more rows — **Integrations**, **API Keys**, **Invitations**, **Personal API Keys**, and **CLI Access** — apply on the group in front of you for anything scoped to one of its workspaces. The account-level path of the same action falls back to the default group: minting a personal key, an organization-wide invitation, an account-level CLI login. To close one of these completely, set it on the default group as well.
 
 ### 4. Choose who it applies to
 
-A workspace-scoped group applies to **all members of its workspaces by default** — including external members. To restrict it to specific people instead, open the group's **Details → General** tab and add members by searching your organization by name or email. Removing every member returns the group to governing everyone in its workspaces.
-
 A user is governed by one group per workspace, so adding a user is rejected when it would conflict with another of their groups on a shared workspace (skipped rather than added in bulk). The default group ignores members entirely — it always governs everyone not covered by a workspace group.
 
 A workspace also has at most one all-members group. Adding a workspace to a group, or removing a group's last member, is rejected when doing so would violate that — memberships and scopes are never silently moved.
 
@@ -14,7 +14,7 @@ A custom block always runs the **latest deployed version** of its source workflo
 
 ## Common uses
 
-Custom blocks turn a workflow one team owns into infrastructure the whole organization can safely reuse. Credentials and complexity stay with the block's author; everyone else gets a clean block that's always up to date. A few patterns:
+The block's author keeps the credentials and the workflow logic; consumers see only the inputs and outputs. Common patterns:
 
 - **Internal API gateway.** Wrap an authenticated internal or partner endpoint — "Create Ticket", "Charge Account", "Provision User" — behind a block that takes only the business inputs. Teammates call it without the base URL, API key, or auth headers, and when the endpoint changes you update one workflow instead of every consumer's.
 - **Blessed knowledge lookup.** Package a vetted retrieval pipeline — chunking, filters, reranking — as "Search Company Docs" with a single query input, so teams reuse the approved retrieval instead of each rebuilding it.
@@ -90,13 +90,13 @@ Click **Save changes**. The block is published immediately and becomes available
 
 ## Using a custom block
 
-In the workflow editor, open the block toolbar. Published custom blocks appear under a **Custom blocks** section. Drag one onto the canvas like any other block, fill in its inputs (using the placeholders as a guide), and reference its outputs in downstream blocks.
+In the workflow editor, open the block toolbar. Published custom blocks appear under a **Custom blocks** section. Drag one into your workflow like any other block, fill in its inputs (using the placeholders as a guide), and reference its outputs in downstream blocks.
 
 <Image src="/static/enterprise/custom-blocks-toolbar.png" alt="Workflow editor block toolbar with a Custom Blocks section listing two published blocks below Core Blocks" width={400} height={476} />
 
 Consumers don't need any access to the source workflow. The block runs on its own, using only the inputs provided, and returns only the outputs you exposed. Its internal steps, models, and intermediate values stay hidden unless the block's publisher turned on **Trace runs in consumer logs**, in which case they appear under the block in the run's trace.
 
-<Image src="/static/enterprise/custom-blocks-canvas.png" alt="A custom block connected to a Start block on the workflow canvas, with its query input filled in and the run output showing the returned fields" width={900} height={570} />
+<Image src="/static/enterprise/custom-blocks-canvas.png" alt="A custom block connected to a Start block in the workflow editor, with its query input filled in and the run output showing the returned fields" width={900} height={570} />
 
 ---
 
 
@@ -187,7 +187,7 @@ The **last 10 runs** for each drain are visible by expanding its row in the sett
 
 ## Pairing with Data Retention
 
-Drains and [Data Retention](/platform/enterprise/data-retention) are independent modules. Sim does **not** gate retention on drain progress — if a drain is failing, retention will still purge data on its own schedule. This matches the model used by Datadog Archives and AWS CloudWatch + S3 Export: keep the two configurations orthogonal and let the customer pair them deliberately.
+Drains and [Data Retention](/platform/enterprise/data-retention) are independent modules. Sim does **not** gate retention on drain progress — if a drain is failing, retention will still purge data on its own schedule. Keep the two configurations independent and pair them deliberately.
 
 To safely use both together, set the drain cadence shorter than the retention period for the same data category:
 
@@ -260,4 +260,4 @@ curl -H "Authorization: Bearer $CRON_SECRET" \
   https://sim.example.com/api/cron/run-data-drains
 ```
 
-Each due drain is then fanned out as a `run-data-drain` background job, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, and a configured Trigger.dev project. Without it the dispatcher still claims the work and enqueues it to the database, but nothing drains that queue for this job type, so the runs stay pending and never execute. See [background jobs](/platform/self-hosting/background-jobs).
+Each due drain is then fanned out as a `run-data-drain` background job, so the deployment also needs `TRIGGER_DEV_ENABLED` and a configured Trigger.dev project. Without it the dispatcher still claims the work and enqueues it to the database, but nothing drains that queue for this job type, so the runs stay pending and never execute. See [background jobs](/platform/self-hosting/background-jobs).
@@ -205,7 +205,7 @@ curl -H "Authorization: Bearer $CRON_SECRET" \
   https://sim.example.com/api/logs/cleanup
 ```
 
-Each call fans the work out as background jobs, so the deployment also needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, and a configured Trigger.dev project. Without it the dispatcher still claims the work and enqueues it to the database, but nothing drains that queue for this job type, so the runs stay pending and never execute.
+Each call fans the work out as background jobs, so the deployment also needs `TRIGGER_DEV_ENABLED` and a configured Trigger.dev project. Without it the dispatcher still claims the work and enqueues it to the database, but nothing drains that queue for this job type, so the runs stay pending and never execute.
 
 ### PII redaction
 
 
@@ -361,7 +361,7 @@ Schedules, webhooks, and triggers are not live in the child until you **deploy**
 
 ## Edge cases to keep in mind
 
-- **Force overwrite** — Sync does not merge canvas changes. Anything only on the target that conflicts with the source’s deployed workflows can be lost. Use the confirm dialog’s archive list carefully.
+- **Force overwrite** — Sync does not merge editor changes. Anything only on the target that conflicts with the source’s deployed workflows can be lost. Use the confirm dialog’s archive list carefully.
 - **Deselect on fork** — Cleared references are intentional. Prefer copying the resource, or plan to reconnect it in the child.
 - **Background copy** — Right after fork, large tables / knowledge bases / files may still be copying. Check **Activity** if something looks empty.
 - **OAuth MCP** — Expect a reconnect in the child (and after a copied server on sync).
 
@@ -3,7 +3,7 @@ title: Enterprise
 description: Enterprise features for business organizations
 ---
 
-Sim Enterprise adds fine-grained access control, SSO, audit logging, compliance features, and workspace forking on top of Team plans.
+Sim Enterprise adds permission groups, SSO, audit logs, usage tracking, data retention and drains, white-labeling, and workspace forks on top of Team plans.
 
 ---
 
@@ -21,7 +21,7 @@ External workspace members can be governed by permission groups just like intern
 
 ### Setup
 
-1. Navigate to **Settings** → **Organization** → **Permission groups** from any workspace in your organization
+1. Navigate to **Settings → Organization → Permission groups** from any workspace in your organization
 2. Create a permission group with your desired restrictions
 3. Scope it to workspaces, and optionally add named members
 
@@ -65,7 +65,7 @@ Configure how long execution logs, soft-deleted resources, and Chat data are kep
 
 ## Data Drains
 
-Continuously export workflow logs, audit logs, and Chat data to a customer-owned S3 bucket or HTTPS webhook on a schedule. See the [data drains guide](/platform/enterprise/data-drains).
+Continuously export workflow logs, audit logs, and Chat data to a destination you control — object storage, a data warehouse, Datadog, or an HTTPS webhook — on a schedule. See the [data drains guide](/platform/enterprise/data-drains).
 
 ---
 
 
@@ -25,8 +25,7 @@ NEXT_PUBLIC_ENTERPRISE_ENABLED=true
 
 That turns on organizations, permission groups, SSO, white-labeling, audit logs,
 usage tracking, custom blocks, session policies, data retention, data drains, workspace
-forks, the Sandbox entitlement, and the inbox. Sandboxes remain unavailable until their
-remote provider and dedicated Function base are configured.
+forks, the Sandbox entitlement, and the inbox.
 
 ### Turning one feature off
 
@@ -64,13 +63,13 @@ JavaScript without `import` or `require` does not use the remote provider and co
 
 See [Sandboxes](/platform/self-hosting/sandboxes) for the provider credentials, the Function base-image build, and the promotion procedure.
 
-<Callout type="warning">
+<Callout type="warn">
   Data retention is the one feature that deletes data. Its flag controls the cleanup pass, not the settings screen — retention windows are always configurable. Nothing is ever deleted until you enable it, and even then only against windows you configured explicitly. Sim never applies the hosted plan defaults to a self-hosted deployment.
 </Callout>
 
 ## Schedule the background jobs
 
-Two enterprise features do their work from a cron-driven HTTP endpoint rather than from the app process. Both endpoints authenticate with a bearer token equal to `CRON_SECRET`, and both return `401` when `CRON_SECRET` is unset:
+Two enterprise features do their work from a cron-driven HTTP endpoint rather than from the app process. All four endpoints authenticate with a bearer token equal to `CRON_SECRET`, and both return `401` when `CRON_SECRET` is unset:
 
 ```bash
 CRON_SECRET=$(openssl rand -hex 32)
@@ -83,7 +82,7 @@ CRON_SECRET=$(openssl rand -hex 32)
 | Retention — soft deletes | `GET /api/cron/cleanup-soft-deletes` | Daily | **No** |
 | Retention — Chat tasks | `GET /api/cron/cleanup-tasks` | Daily | **No** |
 
-<Callout type="warning">
+<Callout type="warn">
   The Helm chart schedules the data-drain dispatcher but **not** the three retention cleanup endpoints. Setting `DATA_RETENTION_ENABLED=true` on the chart alone deletes nothing — the windows are evaluated only when one of those endpoints is called. Add them to `cronjobs.jobs` yourself, or drive them from an external scheduler.
 </Callout>
 
@@ -92,7 +91,7 @@ curl -H "Authorization: Bearer $CRON_SECRET" \
   https://sim.example.com/api/logs/cleanup
 ```
 
-Both features also fan work out as background jobs, so the deployment needs `TRIGGER_DEV_ENABLED` with a configured Trigger.dev project, and a configured Trigger.dev project. Without it the dispatcher still claims the work and enqueues it to the database, but nothing drains that queue for this job type, so the runs stay pending and never execute. See [background jobs](/platform/self-hosting/background-jobs).
+Both features also fan work out as background jobs, so the deployment needs `TRIGGER_DEV_ENABLED` and a configured Trigger.dev project. Without it the dispatcher still claims the work and enqueues it to the database, but nothing drains that queue for this job type, so the runs stay pending and never execute. See [background jobs](/platform/self-hosting/background-jobs).
 
 ## Choose an organization model
 
 
@@ -60,7 +60,7 @@ Use this after a security incident, an offboarding wave, or before tightening a
     {
       question: 'What happens to a member who is working when their session expires?',
       answer:
-        'They are redirected to sign in again on their next request. Unsaved workflow changes in the editor are preserved by the collaborative canvas, which continuously syncs edits.',
+        'They are redirected to sign in again on their next request. Unsaved workflow changes in the editor are preserved by the collaborative editor, which continuously syncs edits.',
     },
     {
       question: 'Does "Sign out all members" affect API keys or running workflows?',
Original file line number	Diff line number	Diff line change
`@@ -60,7 +60,7 @@ Use this after a security incident, an offboarding wave, or before tightening a`
`60`	`60`	`{`
`61`	`61`	`question: 'What happens to a member who is working when their session expires?',`
`62`	`62`	`answer:`
`63`		`- 'They are redirected to sign in again on their next request. Unsaved workflow changes in the editor are preserved by the collaborative canvas, which continuously syncs edits.',`
	`63`	`+ 'They are redirected to sign in again on their next request. Unsaved workflow changes in the editor are preserved by the collaborative editor, which continuously syncs edits.',`
`64`	`64`	`},`
`65`	`65`	`{`
`66`	`66`	`question: 'Does "Sign out all members" affect API keys or running workflows?',`