feat(organizations): sweep a joiner's owned workspaces into the org on join, disclose it at accept, and add external workspace invites

apps/docs/app/[lang]/[[...slug]]/page.tsx

@@ -121,7 +121,7 @@ export default async function Page(props: { params: Promise<{ slug?: string[]; l
     const urlParts = page.url.split('/').filter(Boolean)
     let currentPath = ''
 
-    urlParts.forEach((part, index) => {
+    urlParts.forEach((part: string, index: number) => {
       if (index === 0 && SUPPORTED_LANGUAGES.has(part)) {
         currentPath = `/${part}`
         return
@@ -131,7 +131,7 @@ export default async function Page(props: { params: Promise<{ slug?: string[]; l
 
       const name = part
         .split('-')
-        .map((word) => word.charAt(0).toUpperCase() + word.slice(1))
+        .map((word: string) => word.charAt(0).toUpperCase() + word.slice(1))
         .join(' ')
 
       if (index === urlParts.length - 1) {

apps/docs/app/api/chat/route.ts

@@ -1,7 +1,13 @@
 import { openai } from '@ai-sdk/openai'
-import { convertToModelMessages, stepCountIs, streamText, tool, type UIMessage } from 'ai'
+import {
+  convertToModelMessages,
+  jsonSchema,
+  stepCountIs,
+  streamText,
+  tool,
+  type UIMessage,
+} from 'ai'
 import { sql } from 'drizzle-orm'
-import { z } from 'zod'
 import { db, docsEmbeddings } from '@/lib/db'
 import { generateSearchEmbedding } from '@/lib/embeddings'
 
@@ -332,8 +338,21 @@ export async function POST(req: Request) {
       searchDocs: tool({
         description:
           'Search the Sim documentation for relevant content. Use this before answering any question about Sim.',
-        inputSchema: z.object({
-          query: z.string().describe('A focused natural-language search query.'),
+        /**
+         * The SDK's own schema helper instead of a zod schema: the `ai`
+         * package's zod-v4 typings lag the workspace zod version, so a zod
+         * object here fails the tool() overloads whenever the two drift.
+         */
+        inputSchema: jsonSchema<{ query: string }>({
+          type: 'object',
+          properties: {
+            query: {
+              type: 'string',
+              description: 'A focused natural-language search query.',
+            },
+          },
+          required: ['query'],
+          additionalProperties: false,
         }),
         execute: async ({ query }) => searchDocs(query, locale),
       }),

apps/docs/content/docs/en/platform/costs.mdx

@@ -321,7 +321,7 @@ By default, your usage is capped at the credits included in your plan. To allow
 | **Max** | Up to 10 | — |
 | **Team / Enterprise** | — | Unlimited (Owners and Admins) |
 
-Team and Enterprise plans unlock shared workspaces that belong to your organization. Every workspace created under a Team or Enterprise plan is organization-owned: Owners and Admins can create unlimited shared workspaces, while organization Members cannot create workspaces (personal workspaces created before joining the organization remain accessible). Internal members invited to a shared workspace join the organization and count toward your seat total — Enterprise invites require an available seat at invite time, while Team plans add a seat automatically when the invitee accepts. Existing Sim users who already belong to another organization can be added as external workspace members; they get workspace access without joining your organization or using one of your seats. When a Team or Enterprise subscription is cancelled or downgraded, existing shared workspaces remain accessible to current members but new invites are disabled until the organization is upgraded again.
+Team and Enterprise plans unlock shared workspaces that belong to your organization. Every workspace created under a Team or Enterprise plan is organization-owned: Owners and Admins can create unlimited shared workspaces, while organization Members cannot create workspaces. When someone joins the organization as an internal member, personal workspaces they own move into the organization and their usage is billed to it from then on. Internal members count toward your seat total — Enterprise invites require an available seat at invite time, while Team plans add a seat automatically when the invitee accepts. External workspace members get access to specific workspaces without joining your organization or using one of your seats; they must already be on a paid Sim plan (their own Pro or Max subscription, or another organization that seats them), and invitees who already belong to another organization always join this way. When a Team or Enterprise subscription is cancelled or downgraded, existing shared workspaces remain accessible to current members but new invites are disabled until the organization is upgraded again.
 
 ### Rate Limits
 

apps/docs/content/docs/en/platform/permissions.mdx

@@ -37,7 +37,7 @@ Inherited roles are **automatic and locked**. In member lists they show greyed o
 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. Internal members invited to a shared workspace join the organization and count toward your seat total. Existing Sim users who already belong to another organization can be added as external workspace members instead, giving them access to the workspace without adding them to your organization roster or using one of your seats.
+- **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](#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
 
@@ -48,7 +48,7 @@ Sim has two kinds of workspaces:
 | **Max** | Up to 10 | — |
 | **Team / Enterprise** | — | Unlimited (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 created before joining the organization remain accessible. Enterprise invites require an available seat at invite time; on Team plans, a seat is added automatically when the invitee accepts.
+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](#joining-an-organization). Enterprise invites require an available seat at invite time; on Team plans, a seat is added automatically when the invitee accepts.
 
 <Callout type="info">
   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.
@@ -60,6 +60,12 @@ On Team and Enterprise plans, every workspace you create belongs to the organiza
   <Video src="invitations.mp4" width={700} height={450} />
 </div>
 
+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:
@@ -75,10 +81,29 @@ When inviting someone to a workspace, you can assign one of three permission lev
 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 workspace they are invited to. They keep their own organization membership, do not appear in your organization roster, and do not count toward your organization's seats. Use external access for clients, partners, contractors, or collaborators who already use Sim in another organization.
+- **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](#how-roles-inherit), 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:
@@ -147,7 +172,7 @@ Any Admin — whether invited directly or an admin by way of their organization
 2. **Workspace level**: Give them **Admin** permission so they can manage the team and see everything
 
 ### Adding a Stakeholder or Client
-1. **Organization level**: If they should not join your organization, add them as an **External workspace member**
+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
 
 ---
@@ -221,11 +246,13 @@ import { FAQ } from '@/components/ui/faq'
 
 <FAQ items={[
   { question: "What is the difference between organization roles and workspace permissions?", answer: "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." },
+  { question: "What happens to my personal workspaces when I join an organization?", answer: "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." },
+  { question: "What happens when a member is removed from the organization?", answer: "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." },
   { question: "What happens to my shared workspaces if I cancel or downgrade my Team plan?", answer: "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." },
   { question: "Can I restrict which integrations or model providers a team member can use?", answer: "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." },
   { question: "What happens when a personal environment variable has the same name as a workspace variable?", answer: "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." },
   { question: "Can an Admin remove the workspace owner?", answer: "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." },
   { question: "Who can manage a workspace's credentials and secrets?", answer: "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." },
   { question: "What are permission groups and how do they work?", answer: "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." },
-  { question: "How should I set up permissions for a new team member?", answer: "Start with the lowest permission level they need. Invite teammates to the organization as Members, 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. For clients, partners, or users who already belong to another Sim organization, use external workspace access so they can collaborate without joining your organization or consuming a seat." },
+  { question: "How should I set up permissions for a new team member?", answer: "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." },
 ]} />