docs(forks): document opt-in fork sync for new workflows

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: mzxchandra

apps/docs/content/docs/platform/enterprise/forks.mdx

@@ -54,10 +54,12 @@ Everything under **Copy resources** starts **selected**. That is usually what yo
 
 <Image src="/static/enterprise/forks-create-warning.png" alt="Fork workspace modal showing a warning that deselected resources will clear references in the fork" width={900} height={953} className="mx-auto h-auto w-full max-w-md" />
 
+If the source has deployed workflows that are **not** in fork sync (see [Synced workflows](#synced-workflows)), a **Workflows** section appears with a **Copy unsynced workflows** toggle. It is **off**, so a fork carries exactly what the Forks page shows as synced. Turn it on to copy every deployed workflow instead — the unsynced ones arrive in the child still unsynced, so they never sync back. Either way the line under the toggle names the counts.
+
 Click **Fork**. The child workspace is created immediately. Deployed workflows land as **drafts** in the child. Large content (table rows, knowledge base files, file blobs) may finish copying in the background — watch **Activity** on the source workspace.
 
 <Callout type="info">
-  Only **deployed** workflows are forked. Drafts and undeployed work stay in the parent. If the parent has nothing deployed, the child starts with a blank starter workflow.
+  Only **deployed** workflows are forked, and by default only the ones that are [synced](#synced-workflows). Drafts and undeployed work stay in the parent. If there is nothing to copy, the child starts with a blank starter workflow.
 </Callout>
 
 ### 3. Open the parent edge (from the child)
@@ -117,16 +119,35 @@ On success you will see a toast such as **Pushed to "…"** or **Pulled from "
 
 ---
 
-## Excluded workflows
+## Synced workflows
+
+The **Synced workflows** section on the Forks page lists this workspace's deployed workflows in their sidebar folder structure, each with a checkbox. **Checked means the workflow syncs.** Uncheck one — or a whole folder at once — to keep it out of forking entirely. Think of an unchecked workflow as `.gitignore`d:
+
+- **Never sent** — pushes from this workspace do not carry it, the other side pulling from this workspace does not receive it, and creating a new fork does not copy it (unless you turn on **Copy unsynced workflows** in the fork modal)
+- **Never touched** — a sync into this workspace will not overwrite or archive it, even if its counterpart was deleted on the other side. It stays deployed and keeps serving, and a previously-synced counterpart on the other side keeps running on its last deployed version.
+
+The checkbox list belongs to **this workspace's copy** only. Unchecking a workflow here does not unsync its counterpart in the parent or a fork — each workspace manages its own list. If the pair has synced before, the link between them is kept, so re-checking later resumes updating the same counterpart instead of creating a duplicate.
+
+On the sync page, unsynced workflows still appear in the **Deployed workflows** list, greyed out, with a tooltip naming which workspace they are unsynced in. The sync will not touch them.
+
+**Example:** a staging fork leaves `Scratch experiment` unchecked so it can never reach production, and production leaves `Billing hotfix` unchecked so no push from staging can ever overwrite it.
+
+### Sync new workflows by default
+
+Above the list, **Sync new workflows by default** decides where a **newly created** workflow starts:
 
-The **Excluded workflows** section on the Forks page lists this workspace's deployed workflows in their sidebar folder structure. Check a workflow — or a whole folder at once — to keep it out of forking entirely. Think of it as a `.gitignore` for syncs:
+| Setting | A new workflow… |
+|---------|-----------------|
+| **On** (default) | joins fork sync — it arrives checked and syncs as soon as you deploy it |
+| **Off** | starts outside fork sync — it arrives unchecked and only syncs after you check it |
 
-- **Never sent** — pushes from this workspace do not carry it, the other side pulling from this workspace does not receive it, and creating a new fork does not copy it
-- **Never touched** — a sync into this workspace will not overwrite or archive it, even if its counterpart was deleted on the other side
+Three things to know:
 
-The setting belongs to **this workspace's copy** only. Excluding a workflow here does not exclude its counterpart in the parent or a fork — each workspace manages its own list. If the pair has synced before, the link between them is kept, so un-excluding later resumes updating the same counterpart instead of creating a duplicate.
+- **It applies to the whole fork lineage.** The toggle writes every workspace in the lineage — the root, every ancestor, every descendant — so a parent and its forks can never disagree about what "new" means. Any workspace admin in the lineage can change it, and each member gets its own audit entry naming the workspace the change came from. A new fork inherits the value at creation.
+- **It is forward-only.** Flipping it never moves an existing workflow in or out of sync. The checkbox list above stays the record of what syncs.
+- **"New" means genuinely new.** Creating, duplicating, or importing a workflow takes this setting, as does the blank starter workflow a fork gets when there is nothing to copy. A workflow that arrives as a **copy** — from a fork, or from a push or pull — inherits its source's own checkbox instead, so a workflow you deliberately synced never lands unsynced in the child.
 
-**Example:** a staging fork excludes `Scratch experiment` so it can never reach production, and production excludes `Billing hotfix` so no push from staging can ever overwrite it.
+**Example:** a template workspace turns this off so every scratch workflow the team creates stays local, then checks only the handful meant to reach the forks.
 
 ---
 
@@ -155,6 +176,8 @@ Expand a row for names of workflows and resources that were created, updated, or
 |--------|-----|
 | See Forks / create a fork | Admin on this workspace (+ feature available) |
 | Sync / edit mappings | Admin on **both** sides of the edge |
+| Check / uncheck **Synced workflows** | Admin on the workspace those workflows live in |
+| Change **Sync new workflows by default** | Admin on any one workspace in the lineage — the change applies to every member |
 | Rollback | Admin on the workspace the sync landed in |
 | Disconnect | Admin on **this** side only (you can disconnect even without access to the other workspace) |
 | Open the other workspace | You must be a member of that workspace |
@@ -169,9 +192,9 @@ How each resource behaves at **fork** time vs **sync** time. Use this when you a
 
 | Resource | Fork | Sync |
 |----------|------|------|
-| Deployed workflows | Copied as drafts (unless excluded) | Updated / created / archived (force overwrite) |
+| Deployed workflows | Copied as drafts when [synced](#synced-workflows) | Updated / created / archived (force overwrite) |
 | Undeployed workflows | Not copied | Not synced |
-| [Excluded workflows](#excluded-workflows) | Never | Never — not sent, not overwritten, not archived |
+| [Unsynced workflows](#synced-workflows) | Only via **Copy unsynced workflows**, and the copy lands unsynced | Never — not sent, not overwritten, not archived |
 | Files | Optional copy (default on) | Map or copy |
 | File folders referenced by workflows | Mirrored with their ancestor folders, even when empty | Map by canonical path |
 | Tables | Optional copy (default on) | Map or copy |
@@ -191,11 +214,11 @@ How each resource behaves at **fork** time vs **sync** time. Use this when you a
 
 ### Workflows
 
-Only **deployed** workflows move. Deploy is the commit; sync is the force push/pull of those commits. Workflows marked [excluded](#excluded-workflows) never move in either direction.
+Only **deployed** workflows move, and only the ones checked under [Synced workflows](#synced-workflows). An unsynced workflow never moves in either direction — the one exception is the fork modal's **Copy unsynced workflows** override, which copies it once and leaves it unsynced in the child.
 
 | Feature | Behavior |
 |---|----------|
-| **Fork** | Each deployed workflow becomes a **draft** in the child. Run history is not copied. Only folders that contain a copied workflow are kept. |
+| **Fork** | Each synced deployed workflow becomes a **draft** in the child. Run history is not copied. Only folders that contain a copied workflow are kept. |
 | **Sync** | The change list shows what will be updated, created, or archived. The target is overwritten for those workflows. |
 
 **Example:** Parent has `Support triage` deployed and `WIP experiment` as a draft. The fork gets only `Support triage` as a draft. A later push updates the child from the parent’s latest deploy of `Support triage`.
@@ -370,13 +393,16 @@ Schedules, webhooks, and triggers are not live in the child until you **deploy**
 - **Rollback ≠ undo copies** — Workflow versions roll back; copied resources can remain as orphans.
 - **Disconnect is permanent** — You cannot “reconnect” the same edge; you would fork again into a new workspace.
 - **No grandparent sync** — Only the direct parent↔child pair.
+- **The sync default is lineage-wide** — **Sync new workflows by default** is one shared setting for the whole lineage, so changing it from a fork also changes it in the parent and every sibling fork.
 
 ---
 
 <FAQ items={[
   { question: "Why is Sync greyed out?", answer: "Usually a blocking reference, an unmapped credential or secret, or a required dependent field (label, channel, document, …) still empty. Open Blocking sync and the mapping sections — each row explains what to fix. Sync also stays disabled while details are loading or if loading failed (reload the page)." },
   { question: "Is sync a merge?", answer: "No. Deploy is like a commit; sync is a force push or force pull of deployed workflows onto the target. Use Rollback only for the last sync into a workspace, and remember copied resources may remain." },
-  { question: "Who can disconnect a fork I cannot open?", answer: "Any admin on your side of the edge. Disconnect does not require access to the other workspace — so you are not stuck if the other side lost membership." }
+  { question: "Who can disconnect a fork I cannot open?", answer: "Any admin on your side of the edge. Disconnect does not require access to the other workspace — so you are not stuck if the other side lost membership." },
+  { question: "I deployed a new workflow and sync ignored it. Why?", answer: "Sync new workflows by default is off for this fork lineage, so the workflow was created outside fork sync. Open Settings → Organization → Workspace forks and check it under Synced workflows. Turning the toggle back on only affects workflows created after that — it never moves an existing one." },
+  { question: "Does turning Sync new workflows by default off stop my current syncs?", answer: "No. It is forward-only and never rewrites an existing workflow's checkbox, so everything already synced keeps syncing. It also applies to every workspace in the fork lineage, not just the one you changed it from." }
 ]} />
 
 ---