diff --git a/apps/sim/app/(landing)/comparison/comparison-sections.ts b/apps/sim/app/(landing)/comparison/comparison-sections.ts
index 5c534486c9b..825abdfa23d 100644
--- a/apps/sim/app/(landing)/comparison/comparison-sections.ts
+++ b/apps/sim/app/(landing)/comparison/comparison-sections.ts
@@ -70,6 +70,7 @@ export const COMPARISON_SECTIONS: ComparisonSectionDef[] = [
       { key: 'dataTables', label: 'Native data tables' },
       { key: 'richTextEditor', label: 'Rich-text document editor' },
       { key: 'subWorkflows', label: 'Sub-workflows (composition)' },
+      { key: 'customBlocks', label: 'Custom blocks (org-wide reuse)' },
     ],
   }),
   defineSection({
diff --git a/apps/sim/lib/compare/data/competitors/claude-cowork.ts b/apps/sim/lib/compare/data/competitors/claude-cowork.ts
index 911297747a1..786c7c99e58 100644
--- a/apps/sim/lib/compare/data/competitors/claude-cowork.ts
+++ b/apps/sim/lib/compare/data/competitors/claude-cowork.ts
@@ -329,6 +329,26 @@ export const claudeCoworkProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "No: Claude Cowork has no visual workflow builder, so there is no completed workflow to publish as a reusable block. The closest adjacent capability is org-wide Skills sharing: a member enables 'Share with organization' on a Skill (a SKILL.md instruction file, optionally with reference docs/scripts), and it becomes available to everyone in Customize > Skills. Recipients can enable and use a shared Skill but cannot edit its contents.",
+        detail:
+          "This does not meet the bar of a published-workflow-as-block. A Skill is read-only prompt/instruction text Claude consults at runtime, not an encapsulated, deployed multi-step workflow with auto-derived inputs, hand-picked named outputs, and a hidden internal implementation that always tracks the source's latest version. Cowork Projects, the closest thing to a saved unit of work, explicitly do not support sharing for members of Team and Enterprise plans; separately, Anthropic notes projects are 'desktop-only and stored locally,' with no cloud sync.",
+        shortValue: 'No: no publish-workflow-as-block feature exists',
+        confidence: 'verified',
+        sources: [
+          {
+            url: 'https://support.claude.com/en/articles/13119606-provision-and-manage-skills-for-your-organization',
+            label: 'Provision and manage skills for your organization',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://support.claude.com/en/articles/14116274-organize-your-tasks-with-projects-in-claude-cowork',
+            label: 'Organize your tasks with projects in Claude Cowork',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/crewai.ts b/apps/sim/lib/compare/data/competitors/crewai.ts
index 3447689c34f..5d6327facb0 100644
--- a/apps/sim/lib/compare/data/competitors/crewai.ts
+++ b/apps/sim/lib/compare/data/competitors/crewai.ts
@@ -331,6 +331,32 @@ export const crewaiProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          'No: no documented feature to publish a deployed crew/flow as an encapsulated, org-wide reusable block',
+        detail:
+          "CrewAI AMP's Tool Repository publishes individual custom Tools (single Python functions/classes wrapping an API) to a shared, permissioned catalog, not entire crews or flows. No CrewAI source describes taking a deployed crew or flow and publishing it as a named, iconed block that appears in a shared builder palette for other org members to drop into their own separate crews, with internals hidden and the block auto-tracking the source's latest deployed version. The closest pattern, wrapping a Crew's kickoff as a callable Tool for another Crew, is discussed only as a same-project code workaround in CrewAI's community forum, not a first-party, org-wide publish-as-block feature.",
+        shortValue:
+          'No, Tool Repository publishes single Tools, not published crews/flows as blocks',
+        confidence: 'estimated',
+        sources: [
+          {
+            url: 'https://docs.crewai.com/en/enterprise/guides/tool-repository',
+            label: 'Tool Repository - CrewAI Docs',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.crewai.com/en/enterprise/features/crew-studio',
+            label: 'Crew Studio - CrewAI Docs',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://community.crewai.com/t/crew-method-as-tool/400',
+            label: 'Crew method as tool - CrewAI Community',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/dust.ts b/apps/sim/lib/compare/data/competitors/dust.ts
index 7532abc705a..3f4aaba8ae9 100644
--- a/apps/sim/lib/compare/data/competitors/dust.ts
+++ b/apps/sim/lib/compare/data/competitors/dust.ts
@@ -337,6 +337,26 @@ export const dustProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          'No: Dust has no way to publish an agent as a named, encapsulated block that appears in a shared builder toolbox for other users, with its internals hidden and the source kept in sync',
+        detail:
+          'The closest Dust feature is Skills, a reusable package of instructions, knowledge, and tools attached to multiple agents with edits auto-propagating, but Dust\'s own docs describe Skills as explicitly transparent rather than encapsulated: a read-only summary of every referenced instruction, tool, and knowledge source is shown to whoever authors it in the Skill Editor, not hidden behind an interface exposing only defined inputs/outputs. The separate "Run agent" tool (see subWorkflows) lets one agent call another saved agent, but that is picking an existing agent to call from a list, not publishing a workflow as a distinct, iconed block in a builder toolbox with only its inputs/outputs exposed.',
+        shortValue: 'No: Skills are transparent, not encapsulated; no publish-as-block toolbox',
+        confidence: 'estimated',
+        sources: [
+          {
+            url: 'https://docs.dust.tt/docs/skills',
+            label: 'Skills | Dust Docs',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.dust.tt/docs/run-agent',
+            label: 'Run agent | Dust Docs',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/flowise.ts b/apps/sim/lib/compare/data/competitors/flowise.ts
index f39c3a67115..e360f4998af 100644
--- a/apps/sim/lib/compare/data/competitors/flowise.ts
+++ b/apps/sim/lib/compare/data/competitors/flowise.ts
@@ -243,6 +243,26 @@ export const flowiseProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "No: Flowise has no feature for publishing a deployed chatflow/agentflow as a named, encapsulated block that appears in the node palette for other users across an organization. Its closest feature, the Execute Flow node, only lets a flow call another saved flow by name or ID from within the same Flowise instance, passing input and receiving output; the docs describe this as invoking an existing flow, not publishing a version-synced, credential-hidden component into a shared toolbar. Flowise's Custom Tool node is likewise scoped to inline JavaScript written within a single flow, not a published workflow-as-block. There is no documented mechanism that hides a source flow's internal steps/credentials from consumers, restricts a published block via access control/permission groups, or automatically points every consumer at the source flow's latest deployed version.",
+        detail:
+          "This is distinct from Flowise's Execute Flow sub-workflow calling (see subWorkflows above), which is same-instance flow-to-flow composition, not org-wide reuse of a hidden, centrally-updated block by other users.",
+        shortValue: 'No, only same-instance Execute Flow calls; no published org-wide block',
+        confidence: 'estimated',
+        sources: [
+          {
+            url: 'https://docs.flowiseai.com/using-flowise/agentflowv2',
+            label: 'Flowise Docs: Agentflow V2 (Execute Flow node)',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.flowiseai.com/integrations/langchain/tools/custom-tool',
+            label: 'Flowise Docs: Custom Tool',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/gumloop.ts b/apps/sim/lib/compare/data/competitors/gumloop.ts
index 7940fe4e14e..71fe435f9be 100644
--- a/apps/sim/lib/compare/data/competitors/gumloop.ts
+++ b/apps/sim/lib/compare/data/competitors/gumloop.ts
@@ -334,6 +334,31 @@ export const gumloopProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          'No: Gumloop has no feature that publishes an existing deployed workflow as an encapsulated, named block for the whole org to reuse. Subflows let a saved workflow be dropped into other flows as a node, but public docs describe this only as personal/same-project reuse, with no mention of hiding the subflow\'s internal steps or credentials, or of org-wide toolbar placement for other users. The one org-wide, block-like publishing surface Gumloop does have, the Custom Node Builder plus its "Node and Flow Library" Hub, is scoped to single AI-generated code nodes (wrapping an API or script), not a way to turn a multi-step visual workflow into a reusable block.',
+        detail:
+          "Gumloop's docs on Subflows describe only how to nest a saved workflow as a node with Input/Output nodes for parameters, with no documented mechanism for sharing that subflow node to other users, hiding its internal graph from them, or auto-propagating updates when the source workflow changes. Separately, docs.gumloop.com/core-concepts/node_and_flow_library confirms users can share a Custom Node organization-wide ('Share with Organization: Makes the node discoverable by all organization members'), appearing immediately in teammates' node libraries, but the page's substantive sections (Custom Nodes Tab, Sharing Custom Nodes, Publishing Custom Nodes) only ever cover single code-based nodes generated by the Custom Node Builder from a natural-language description, not multi-step canvas workflows. No Gumloop page describes converting an existing built flow into a shareable, encapsulated block the way a Custom Node is shared.",
+        shortValue: "No: Subflows aren't org-shared; org-shared Custom Nodes are code, not flows",
+        confidence: 'estimated',
+        sources: [
+          {
+            url: 'https://docs.gumloop.com/core-concepts/subflows',
+            label: 'Subflows - Gumloop docs',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.gumloop.com/core-concepts/node_and_flow_library',
+            label: 'Node and Workflow Library - Gumloop docs',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://www.gumloop.com/blog/gumloop-custom-nodes',
+            label: 'Gumloop Blog: Gumloop Custom Nodes',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/langchain.ts b/apps/sim/lib/compare/data/competitors/langchain.ts
index fc2c7d98709..2bd50437677 100644
--- a/apps/sim/lib/compare/data/competitors/langchain.ts
+++ b/apps/sim/lib/compare/data/competitors/langchain.ts
@@ -333,6 +333,21 @@ export const langchainProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "No: LangChain/LangGraph has no drag-and-drop block toolbar at all, so there is no way to publish a deployed graph as a named, iconed block that other org members drop into their own separate graphs with auto-derived inputs and curated, renamed outputs. The closest adjacent capability is code-level: the RemoteGraph SDK class lets a developer add another team's deployed graph as a node in their own graph by writing code that points at its deployment URL and graph/assistant name.",
+        detail:
+          "RemoteGraph exposes the same programmatic interface as a locally compiled graph ('as if it were a local graph'), but the consuming developer must hand-write any state-schema-mapping wrapper code themselves, and there is no UI for picking/renaming which outputs to expose or for auto-deriving input fields from the source graph the way a visual builder does. LangChain's own docs describe RemoteGraph purely as an SDK for calling a deployment programmatically, not as a block placed in a shared, org-wide palette alongside built-in nodes.",
+        shortValue: 'No block toolbar exists; closest is code-level RemoteGraph SDK calls',
+        confidence: 'estimated',
+        sources: [
+          {
+            url: 'https://docs.langchain.com/langsmith/use-remote-graph',
+            label: 'How to interact with a deployment using RemoteGraph - Docs by LangChain',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/langflow.ts b/apps/sim/lib/compare/data/competitors/langflow.ts
index e5225280c35..f9d41991de7 100644
--- a/apps/sim/lib/compare/data/competitors/langflow.ts
+++ b/apps/sim/lib/compare/data/competitors/langflow.ts
@@ -265,6 +265,26 @@ export const langflowProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "No: Langflow has no documented mechanism to publish a deployed flow as an encapsulated, named block that appears org-wide in the component sidebar for other users to drop into their own separate flows. The closest features are narrower: grouping components and saving them creates a static snapshot copy in the creating user's own Core components menu, with no documented auto-sync back to a source flow's latest version; and the legacy Langflow Store lets a user publish a component or flow to a public, account-based marketplace rather than a governed, org-scoped, live-linked block. Its Run Flow component (see subWorkflows) is same-project subflow composition, not org-wide reuse by other users.",
+        detail:
+          "Neither mechanism matches Sim's model of a workspace admin publishing a deployed workflow as a block that all consumers see in the shared toolbar, auto-tracks the source's latest deployed version, and hides the source's internal steps and credentials.",
+        shortValue: 'No, only static component snapshots or a public component store',
+        confidence: 'estimated',
+        sources: [
+          {
+            url: 'https://docs.langflow.org/concepts-components',
+            label: 'Langflow Docs: Components overview (grouping and saving components)',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://github.com/langflow-ai/langflow/discussions/4406',
+            label: 'GitHub Discussion 4406: How to save a custom component to the sidebar?',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/make.ts b/apps/sim/lib/compare/data/competitors/make.ts
index 021e2e9c909..210142f1369 100644
--- a/apps/sim/lib/compare/data/competitors/make.ts
+++ b/apps/sim/lib/compare/data/competitors/make.ts
@@ -371,6 +371,31 @@ export const makeProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "No: Make has no feature to publish an existing scenario as an encapsulated, named block that appears in a shared module toolbar for other users across the organization to drop into their own separate scenarios. The closest capabilities are each narrower: 'Call a Scenario' (Subscenarios) can only invoke a scenario already created within the same team, is not exposed as a general block in a module picker, and Make's own docs don't describe it as hiding internal steps or always tracking a source's latest published version. 'Scenarios as AI Agent tools' lets a scenario's defined inputs/outputs be used as a callable tool, but only inside that specific AI Agent's own tool configuration, not as a general-purpose block any builder can add to any regular scenario. The Custom Apps SDK builds brand-new integration connectors that wrap third-party REST APIs; it has no mechanism to package an existing scenario itself as a block.",
+        detail:
+          "Per Make's Subscenarios help doc, you can 'only call a scenario created in your team,' scoping reuse to team boundaries rather than an org-wide block toolbar, with no documented internals-hiding or auto-latest-version guarantee. Per the Scenarios-for-AI-agents help doc, scenario-as-tool configuration happens inside AI Agents' own tab/module, not as a block available to all scenario builders. Per the Custom Apps Developer Hub, Custom Apps exist to integrate a third-party application that has no existing Make app, mapping REST endpoints and auth, not to publish an existing scenario as a reusable block.",
+        shortValue: 'No: no publish-scenario-as-org-wide-block feature',
+        confidence: 'verified',
+        sources: [
+          {
+            url: 'https://help.make.com/subscenarios',
+            label: 'Subscenarios - Make Help Center',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://help.make.com/scenarios-for-ai-agents',
+            label: 'Scenarios for AI agents - Make Help Center',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://developers.make.com/custom-apps-documentation',
+            label: 'Overview | Custom Apps Documentation | Make Developer Hub',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts b/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts
index ddda7ce6d0d..e3601495b91 100644
--- a/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts
+++ b/apps/sim/lib/compare/data/competitors/microsoft-copilot.ts
@@ -375,6 +375,34 @@ export const microsoftCopilotProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "Partial: a published agent flow (with a 'When an agent calls the flow' trigger and a 'Respond to the agent' action) can be added by another maker as a tool, and a published Copilot Studio agent can be added by another maker as a connected-agent tool that always resolves to the source's latest published version — but discovery for both is a per-item share-and-pick model within one environment, not an admin-governed entry that automatically appears in a block toolbar for the whole org, and there is no publisher step to hand-pick and rename a curated subset of outputs the way Sim's Custom Blocks do.",
+        detail:
+          "Adding a flow as an agent-level tool lists qualifying, published flows in the 'Add tool > Flow' picker; Microsoft's docs don't specify how the tool's inputs are derived from the flow's trigger or confirm it always tracks the flow's latest published version. Connected agents are the better-documented half: a maker can turn on 'Let other agents connect to and use this one' on a published agent so any maker who owns it or has it shared with them can add it as a connected-agent tool in their own, separate agent, always using the latest published version after republish. Neither mechanism auto-populates a single, organization-wide block palette; each is discovered per-item through sharing/run permissions, and there's no dedicated step for the publisher to select and rename specific outputs to expose, unlike Sim's Custom Blocks.",
+        shortValue:
+          'Partial: published flows/agents become tools, but via per-item sharing, not an org-wide toolbar',
+        confidence: 'estimated',
+        sources: [
+          {
+            url: 'https://learn.microsoft.com/en-us/microsoft-copilot-studio/flow-agent',
+            label:
+              'Add an agent flow as a tool to an agent - Microsoft Copilot Studio | Microsoft Learn',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-agent-copilot-studio-agent',
+            label:
+              'Connect to an existing Copilot Studio agent - Microsoft Copilot Studio | Microsoft Learn',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-add-other-agents',
+            label: 'Add other agents overview - Microsoft Copilot Studio | Microsoft Learn',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/n8n.ts b/apps/sim/lib/compare/data/competitors/n8n.ts
index 4c8a4468cdb..18322c09408 100644
--- a/apps/sim/lib/compare/data/competitors/n8n.ts
+++ b/apps/sim/lib/compare/data/competitors/n8n.ts
@@ -348,6 +348,27 @@ export const n8nProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          'No: n8n has no feature to publish a deployed workflow as a named, encapsulated block that appears in the node panel for other users to drag into their own separate workflows. The closest built-in mechanism is the Execute Sub-workflow node, which calls another saved workflow (by database lookup, local file, parameter, or URL) from inside a workflow, but it is a generic caller node, not a distinct, iconed, named block per source workflow.',
+        detail:
+          "An n8n community feature request, 'Mark workflow as a custom node to be re-used in other workflows' (opened August 2024), asks for exactly this: turning a workflow into a reusable node listed under its own category in the node panel, with defined input parameters, so other builders can add it without touching the source workflow's internals. n8n has not shipped it; the documented mechanism remains the generic Execute Sub-workflow node. n8n's actual node-level encapsulation mechanism, custom/community nodes, requires writing and packaging real TypeScript code as an npm module, not publishing a no-code workflow someone built visually.",
+        shortValue: 'No, only generic Execute Sub-workflow calls, not a published block',
+        confidence: 'verified',
+        sources: [
+          {
+            url: 'https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.executeworkflow/',
+            label: 'Execute Sub-workflow | Nodes | n8n Docs',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://community.n8n.io/t/mark-workflow-as-a-custom-node-to-be-re-used-in-other-workflows/51808',
+            label:
+              'Mark workflow as a custom node to be re-used in other workflows (n8n Community feature request)',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/openai-agentkit.ts b/apps/sim/lib/compare/data/competitors/openai-agentkit.ts
index f169b874180..c902df21996 100644
--- a/apps/sim/lib/compare/data/competitors/openai-agentkit.ts
+++ b/apps/sim/lib/compare/data/competitors/openai-agentkit.ts
@@ -350,6 +350,26 @@ export const openaiAgentkitProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "No: Agent Builder has no feature to publish a workflow as a named, encapsulated block that other org members can drop into their own separate workflows. Its full node palette (Start, Agent, Note, File search, Guardrails, MCP, If/else, While, Human approval, Transform, Set state) has no 'workflow as a block' node, and publishing only creates a versioned snapshot consumable via the API or embedded through ChatKit, not a reusable canvas block for teammates.",
+        detail:
+          "Publishing a workflow in Agent Builder produces a versioned object callable via API or embeddable through ChatKit, but that is deploying one workflow as an endpoint, not turning it into a block that appears in other users' canvases with inputs auto-derived from its Start node and internals hidden. Team-level reuse in the documented deployment paths (templates, ChatKit, SDK code export) means copying a template, embedding a chat surface, or exporting code, none of which give other builders a live, encapsulated block that stays in sync with the source workflow's latest published version. Agent Builder itself is also being wound down, with full shutdown November 30, 2026.",
+        shortValue: 'No dedicated publish-as-reusable-block feature found',
+        confidence: 'estimated',
+        sources: [
+          {
+            url: 'https://developers.openai.com/api/docs/guides/node-reference',
+            label: 'Node reference | OpenAI API',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://developers.openai.com/api/docs/guides/agent-builder',
+            label: 'Agent Builder | OpenAI API',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/openclaw.ts b/apps/sim/lib/compare/data/competitors/openclaw.ts
index 7a8c563d7b2..86a25169eef 100644
--- a/apps/sim/lib/compare/data/competitors/openclaw.ts
+++ b/apps/sim/lib/compare/data/competitors/openclaw.ts
@@ -362,6 +362,32 @@ export const openClawProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "No: OpenClaw has no feature to publish a Lobster workflow or Task Flow as a named, iconed, encapsulated block that appears in a shared toolbar for other org members to drop into their own separate flows. The documented path for org-wide reuse is packaging a `.lobster` file plus setup notes as a Skill or plugin and publishing it through ClawHub, an installable instruction/code package the agent references, not a live block whose inputs/outputs are auto-derived from a source workflow and that tracks that workflow's latest deployed version automatically.",
+        detail:
+          "Lobster's own docs list run/command, pipeline, and approval as its only step types, with no invoke-another-workflow-as-a-block primitive. Task Flow is scoped to tracking state within a single multi-step run, not publishing that run as a reusable component. ClawHub Skills are markdown instruction files compiled into the system prompt for agent reasoning, not encapsulated, auto-input-derived workflow blocks with hand-picked outputs and hidden internals; a published Skill's `.lobster` file and setup notes are visible to whoever installs it, the opposite of Sim's full encapsulation.",
+        shortValue:
+          'No: reuse is via ClawHub Skills (visible instructions), not a live workflow block',
+        confidence: 'estimated',
+        sources: [
+          {
+            url: 'https://docs.openclaw.ai/tools/lobster',
+            label: 'OpenClaw Docs: Lobster',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.openclaw.ai/automation/taskflow',
+            label: 'OpenClaw Docs: Task flow',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.openclaw.ai/tools/skills',
+            label: 'OpenClaw Docs: Skills',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/pipedream.ts b/apps/sim/lib/compare/data/competitors/pipedream.ts
index 4b95969919b..9d938eaa30f 100644
--- a/apps/sim/lib/compare/data/competitors/pipedream.ts
+++ b/apps/sim/lib/compare/data/competitors/pipedream.ts
@@ -308,6 +308,26 @@ export const pipedreamProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "No: Pipedream's closest mechanism is publishing a single Node.js code step as a reusable 'custom action' that shows up under 'My Actions' for other steps to select, not a full multi-step deployed workflow turned into an org-wide toolbar block. The published code stays directly visible and editable to whoever adds it (no encapsulation of internals/credentials), and updates are opt-in: Pipedream's own docs state a new version 'doesn't automatically update all instances of the same action across your workflows... this gives you the control to gradually update.'",
+        detail:
+          "No Pipedream documentation describes taking an entire deployed workflow, auto-deriving its inputs, letting the publisher hand-pick named outputs, and exposing it as a named/iconed block in the builder toolbar for every other team member to drop into their own workflows while always running the source's latest deployed version. 'Sharing Code Across Workflows' scopes reuse to one code step at a time (multi-step reuse requires the CLI to build a full component, which then cannot be edited inline), and the Components docs don't address workflow-to-component conversion at all. Pipedream's registry model is instead built around wrapping third-party API calls into app integrations, not packaging a user's own business-logic workflow as a hidden-internals block.",
+        shortValue: 'No, only single code-step reuse with opt-in updates',
+        confidence: 'verified',
+        sources: [
+          {
+            url: 'https://pipedream.com/docs/workflows/building-workflows/code/nodejs/sharing-code',
+            label: 'Pipedream Docs: Sharing Code Across Workflows',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://pipedream.com/docs/components',
+            label: 'Pipedream Docs: Components Overview',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/power-automate.ts b/apps/sim/lib/compare/data/competitors/power-automate.ts
index 38a53fa2490..0d280672d7b 100644
--- a/apps/sim/lib/compare/data/competitors/power-automate.ts
+++ b/apps/sim/lib/compare/data/competitors/power-automate.ts
@@ -368,6 +368,27 @@ export const powerAutomateProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          'No: Power Automate has no feature to publish a deployed flow as a named, iconed, encapsulated block that shows up in the action picker for the whole tenant/organization. The closest mechanisms are child flows ("Run a Child Flow"), which are scoped to makers with access to the same Dataverse solution, and manually wrapping a flow behind a Custom Connector, which requires hand-authoring an OpenAPI/Swagger definition instead of auto-deriving inputs from the flow.',
+        detail:
+          'Child-flow docs state a maker only sees "the flows only to which you have access and are located in a solution," so reuse is scoped to that solution\'s makers, not the whole org, and a caller can still open the child flow and see its steps and connections, no encapsulation. A Custom Connector can wrap any REST API (including a flow\'s own HTTP-triggered URL) so it appears as a reusable action, but the maker must hand-author or import an OpenAPI/Swagger definition describing its request/response shape, and the connector can be shared within the organization once created; it is the same generic API-wrapping mechanic Power Automate uses for any third-party API, not a one-click "publish this flow as a block" feature with live input derivation, hand-picked outputs, or automatic latest-deployed-version tracking.',
+        shortValue:
+          'No: closest is solution-scoped child flows or manually wrapped custom connectors',
+        confidence: 'verified',
+        sources: [
+          {
+            url: 'https://learn.microsoft.com/en-us/power-automate/create-child-flows',
+            label: 'Create child flows - Power Automate | Microsoft Learn',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://learn.microsoft.com/en-us/connectors/custom-connectors/define-openapi-definition',
+            label: 'Create a custom connector from an OpenAPI definition - Microsoft Learn',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/retool.ts b/apps/sim/lib/compare/data/competitors/retool.ts
index ae3ee288ba6..c64c5a8e7c5 100644
--- a/apps/sim/lib/compare/data/competitors/retool.ts
+++ b/apps/sim/lib/compare/data/competitors/retool.ts
@@ -356,6 +356,26 @@ export const retoolProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          'No: Retool has no way to publish a deployed workflow as a named, encapsulated block that shows up in a shared block library for other builders to drop into their own workflows. The closest primitive is the generic Workflow block (see subWorkflows), which requires manually selecting which saved workflow to call each time it is added, rather than appearing as its own distinct, iconed, org-wide toolbar entry. A public forum feature request asking for exactly this ("Workflow Block Library," save a block once and reuse it across workflows) is still open, with a Retool team member confirming only an internal, unshipped feature request exists for it.',
+        detail:
+          "The Workflow block abstracts away the called workflow's internal steps, but it is one generic block type, not a per-source-workflow custom block, and Retool's docs do not document automatic org-wide distribution or live-sync-to-latest-deploy behavior the way a dedicated published-block feature would.",
+        shortValue: 'No, only a generic workflow-calling block; no published block library',
+        confidence: 'verified',
+        sources: [
+          {
+            url: 'https://community.retool.com/t/workflow-block-library/45360',
+            label: 'Workflow Block Library (Feature Request) - Retool Forum',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.retool.com/workflows/guides/blocks/run-workflow',
+            label: 'Run another workflow with the Workflow block | Retool Docs',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/stackai.ts b/apps/sim/lib/compare/data/competitors/stackai.ts
index 19f22431e97..00a2b46fa57 100644
--- a/apps/sim/lib/compare/data/competitors/stackai.ts
+++ b/apps/sim/lib/compare/data/competitors/stackai.ts
@@ -293,6 +293,26 @@ export const stackaiProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          'No: StackAI has no feature for publishing a project as a named, iconed block that appears in a shared toolbar/library for every builder in the organization. The closest capability is the StackAI Project Node, which lets a builder reference another saved project by picking it from a dropdown inside their own workflow, and Subflow Tools, which do the same from an AI Agent node.',
+        detail:
+          "The Project Node docs describe manually matching the calling workflow's inputs to the target project's inputs (not an auto-derived input schema) and returning results as a single opaque JSON blob covering all of that project's outputs, reshaped afterward with the Output Node's Template feature, rather than the caller picking and naming individual outputs to expose. Neither the Project Node nor Subflow Tools docs describe the referenced project appearing as a distinct block in a shared, org-wide toolbar alongside built-in nodes, hiding its internal steps/credentials from the caller, or automatically tracking a separately published/deployed version of the source project.",
+        shortValue: 'No, only same-workspace Project Node / Subflow Tool references',
+        confidence: 'verified',
+        sources: [
+          {
+            url: 'https://docs.stackai.com/workflow-builder/utils-logic-and-others/utils/stackai-project-node',
+            label: 'StackAI Project Node docs',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.stackai.com/workflow-builder/core-nodes/ai-agent-node/subflow-tools',
+            label: 'Subflow Tools docs',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/tines.ts b/apps/sim/lib/compare/data/competitors/tines.ts
index 0b8e2ed769b..4b095cb920f 100644
--- a/apps/sim/lib/compare/data/competitors/tines.ts
+++ b/apps/sim/lib/compare/data/competitors/tines.ts
@@ -331,6 +331,32 @@ export const tinesProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "No: Tines has no feature that lets a builder publish a Story as its own named, iconed entry in a shared block toolbar. The closest features are (1) Private/Public Templates, which are scoped to configuring a single action (e.g. a pre-built HTTP Request) with parameterized 'Action inputs' that hide that one action's underlying config, and can be shared team-wide or org-wide; and (2) Send to Story, one generic action type used to call any sub-story via a picker — the caller selects the target sub-story and enters its defined parameters, without needing view/edit access to the sub-story's own actions. Neither meets the bar: templates wrap one action, not a multi-step Story, and Send to Story is a single generic action a builder configures per call site, not a distinct block appearing in the toolbar for each published Story.",
+        detail:
+          "Public docs describe template edits as letting a builder 'optionally replace storyboard actions that use the template in one step,' confirming propagation is a manual, opt-in action rather than always running the source's latest deployed version automatically. Send to Story does genuinely hide a sub-story's internals from a caller without permission on it ('will not be able to view or modify the contents of the story unless you have the relevant permissions'), but it is one generic action configured with a target-story picker each time, not a separate published block per Story.",
+        shortValue:
+          'No: templates are single-action; Send to Story is a generic picker, not a block',
+        confidence: 'verified',
+        sources: [
+          {
+            url: 'https://www.tines.com/docs/actions/templates/private-templates/',
+            label: 'Private Templates | Docs | Tines',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://www.tines.com/docs/actions/templates/templates/',
+            label: 'Public Templates | Docs | Tines',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://www.tines.com/docs/stories/send-to-story/',
+            label: 'Send to Story | Docs | Tines',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/vellum.ts b/apps/sim/lib/compare/data/competitors/vellum.ts
index 62939d576e1..8a703b698b3 100644
--- a/apps/sim/lib/compare/data/competitors/vellum.ts
+++ b/apps/sim/lib/compare/data/competitors/vellum.ts
@@ -289,6 +289,32 @@ export const vellumProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "Partial: Vellum has no documented feature for publishing a workflow as a named, iconed block that appears in a shared toolbar for the whole organization. Its closest mechanism is the Deployed Subworkflow node, a dedicated 'Deployed Subworkflow' option in the Insert Node Panel that lets a builder insert an already-deployed workflow as a single node in their own separate workflow, wiring only its defined inputs/outputs rather than exposing the source workflow's internal nodes. Pointing it at the LATEST release tag means it automatically runs the source workflow's newest deployment with no separate republish step.",
+        detail:
+          "Unlike Sim's Custom Blocks, there is no documented step where a publisher assigns a custom name/icon that then surfaces the workflow as a first-class item in the general node toolbar alongside built-in nodes; consumers instead search for and link a specific deployed workflow through the Subworkflow node type. There is also no documented ability to hand-pick and rename a subset of outputs to expose, and no Enterprise-only gating or block-level allow/deny governance specific to this reuse mechanism beyond Vellum's general workspace-wide RBAC roles.",
+        shortValue:
+          'Partial: Deployed Subworkflow node, not a published named/iconed toolbar block',
+        confidence: 'estimated',
+        sources: [
+          {
+            url: 'https://docs.vellum.ai/developers/workflows-sdk/api-reference/nodes/subworkflow-deployment-node',
+            label: 'Subworkflow Deployment Node - Vellum Documentation',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.vellum.ai/changelog/2025/2025-08',
+            label: 'Vellum Changelog: August 2025 (Insert Node Panel Subworkflow split)',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.vellum.ai/product/deployments/release-tags',
+            label: 'Release Tags - Vellum Documentation',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/workato.ts b/apps/sim/lib/compare/data/competitors/workato.ts
index 1e35be93768..71b71548154 100644
--- a/apps/sim/lib/compare/data/competitors/workato.ts
+++ b/apps/sim/lib/compare/data/competitors/workato.ts
@@ -372,6 +372,36 @@ export const workatoProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "No: Workato has no feature to publish a deployed recipe as a distinct, named, iconed block that appears in the recipe builder's general step/action picker for every other builder across the org to drop into their own separate recipes. The closest mechanism, Recipe Functions, lets any recipe in the workspace call another recipe (one built with a 'New function call' trigger) by adding a generic 'Recipe Functions by Workato' connector step and then picking the target function from a dropdown list of saved functions, not a bespoke block with its own name/icon sitting alongside built-in actions. The caller does only see the function's declared Input/Response schema, not its internal steps or credentials, and Workato's own marketing copy states 'update the function once, and the changes will take effect anywhere your function is invoked' (i.e. it always calls the live function recipe, not a frozen copy). No documentation describes per-function governance (allow/deny-listing one specific function for a permission group) distinct from ordinary project/connection-level access control.",
+        detail:
+          "Workato's separate Community Library sharing mechanism is explicitly a clone/template flow, not a live block: shared assets are described as 'intended to serve as a reusable set of templates, best practices and guidelines' for another user to install and then 'modify, customize and enhance' as their own independent copy, with no indication the installed copy stays linked to updates on the original. This rules out Community Library as a second candidate for the same capability.",
+        shortValue: "No, only a generic 'Call Recipe Function' connector, not a published block",
+        confidence: 'verified',
+        sources: [
+          {
+            url: 'https://docs.workato.com/connectors/recipe-functions.html',
+            label: 'Recipe Functions by Workato | Workato Docs',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.workato.com/connectors/recipe-functions/actions/call-recipe-function-synchronously.html',
+            label: 'Recipe Functions - Call Recipe Function Synchronously | Workato Docs',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://www.workato.com/product-hub/recipe-functions-build-reusable-automations/',
+            label: 'How to build reusable automations with Recipe Functions | Workato Product Hub',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.workato.com/community-library.html',
+            label: 'Community library | Workato Docs',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/competitors/zapier.ts b/apps/sim/lib/compare/data/competitors/zapier.ts
index 69c6884799f..467e179f099 100644
--- a/apps/sim/lib/compare/data/competitors/zapier.ts
+++ b/apps/sim/lib/compare/data/competitors/zapier.ts
@@ -338,6 +338,27 @@ export const zapierProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          'No: Zapier has no feature for publishing a deployed Zap as a named, iconed, encapsulated block that appears in the step picker for the whole team to drop into their own separate Zaps. Sub-Zaps are the closest analog, but they are reusable saved steps called by "Call a Sub-Zap," not a org-wide toolbar entry, and Zapier\'s own docs do not describe internals being hidden from other team members who can access the same account. A private integration published on the Developer Platform is a different mechanism: it wraps a third-party API as a connector app for the team, not a workflow.',
+        detail:
+          "Sub-Zaps and private integrations are the two Zapier features that come closest to reuse, but neither matches the mechanics: Sub-Zaps are invoked from a dedicated action step within the same account/team rather than surfaced as a first-class block alongside built-in app steps, and private integrations expose custom API actions, not a published Zap's logic with auto-derived inputs and hand-picked outputs that stay live-synced to a source workflow's latest deployed version.",
+        shortValue:
+          'No equivalent: Sub-Zaps and private integrations are the closest, but neither matches',
+        confidence: 'estimated',
+        sources: [
+          {
+            url: 'https://help.zapier.com/hc/en-us/articles/32283713627533-Understanding-Sub-Zaps',
+            label: 'Understanding Sub-Zaps',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://docs.zapier.com/platform/quickstart/private-vs-public-integrations',
+            label: 'Private vs public integrations',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/sim.ts b/apps/sim/lib/compare/data/sim.ts
index 30e5e49ccbf..88438f5ac66 100644
--- a/apps/sim/lib/compare/data/sim.ts
+++ b/apps/sim/lib/compare/data/sim.ts
@@ -333,6 +333,31 @@ export const simProfile: CompetitorProfile = {
           },
         ],
       },
+      customBlocks: {
+        value:
+          "Yes: a user with admin access on a workflow's workspace can publish its deployed version as a named, iconed custom block that appears in the block toolbar for the whole organization. Inputs are read live from the source workflow's Start block; the publisher picks which outputs to expose. The block always runs the source workflow's latest deployed version, and its internal steps and intermediate values are never exposed to consumers",
+        detail:
+          'Enterprise-gated on Sim Cloud; self-hosted deployments can opt in via a feature flag. Distinct from the Workflow (sub-workflow) block, which composes a workflow the same author controls, and from custom code/tool blocks, which run inline code rather than a full deployed workflow.',
+        shortValue: 'Publish a deployed workflow as an org-wide reusable block',
+        confidence: 'verified',
+        sources: [
+          {
+            url: 'https://github.com/simstudioai/sim/blob/main/apps/sim/app/api/custom-blocks/route.ts',
+            label: 'Sim codebase: custom-blocks publish API (admin gate)',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://github.com/simstudioai/sim/blob/main/apps/sim/blocks/custom/build-config.ts',
+            label: 'Sim codebase: custom-block config builder',
+            asOf: '2026-07-08',
+          },
+          {
+            url: 'https://github.com/simstudioai/sim/blob/main/apps/sim/app/workspace/%5BworkspaceId%5D/settings/navigation.ts',
+            label: 'Sim codebase: Custom blocks nav entry (Enterprise/self-hosted gating)',
+            asOf: '2026-07-08',
+          },
+        ],
+      },
     },
     aiCapabilities: {
       multiLlmSupport: {
diff --git a/apps/sim/lib/compare/data/types.ts b/apps/sim/lib/compare/data/types.ts
index 052823aaef8..91dc96c0065 100644
--- a/apps/sim/lib/compare/data/types.ts
+++ b/apps/sim/lib/compare/data/types.ts
@@ -66,6 +66,8 @@ export interface ComparisonFacts {
     richTextEditor: Fact
     /** Calling one saved workflow as a reusable step inside another workflow (composition/nesting), versus only being able to duplicate or manually re-wire the same logic per workflow. */
     subWorkflows: Fact
+    /** Publishing a deployed workflow/flow as a reusable, named block with its own icon/inputs/outputs that appears in the block toolbar for other org members to drop into their own workflows, without needing access to the underlying flow — distinct from subWorkflows (same-author composition) and from custom code/tool blocks. */
+    customBlocks: Fact
   }
   aiCapabilities: {
     multiLlmSupport: Fact