# Custom blocks (/platform/enterprise/custom-blocks)

Publish a workflow as a custom block so teammates can provide its inputs and use selected outputs without access to its source workflow. The block always runs the source's latest deployment. Use it for a shared knowledge lookup, an authenticated internal API, an enrichment step, or a prompt and guardrail maintained in one place.

Publishing and managing a block requires admin access to its source workspace. Billing-enabled deployments require an Enterprise organization. On billing-disabled deployments, enable the custom-block feature through enterprise configuration or `CUSTOM_BLOCKS_ENABLED=true` and `NEXT_PUBLIC_CUSTOM_BLOCKS_ENABLED=true`. An organization is still required; see [self-hosted enterprise setup](/platform/enterprise/self-hosted).

## Publish a block \[#publish-a-block]

1. Deploy the source workflow.
2. Open **Settings → Workspace → Custom blocks** and click **Create block**.
3. Select its **Workspace** and **Workflow**. The picker lists organization workspaces and deployed workflows. You must be an admin of the selected source workspace.
4. Set the block's presentation and interface using the fields below.
5. Review its trace policy, then click **Save**.

Only one custom block can be published per source workflow. The source is fixed after publication; publishing another workflow requires a separate block.

### Name and icon \[#name-and-icon]

| Field | Behavior |
| - | - |
| **Icon** | Optional square PNG, JPEG, SVG, or WebP, up to 5 MiB. Falls back to the organization logo, then a default glyph. |
| **Name** | Toolbar display name, up to 60 characters. |
| **Description** | Summary of what consumers can do, up to 280 characters. |

### Inputs \[#inputs]

Every input on the deployed workflow's **Start** block becomes a custom-block field, with its name, type, and description. You cannot select only some Start inputs.

For each input, set an optional placeholder of up to 200 characters and use **Required** when consumers must supply it. You can store overrides for up to 50 inputs. Inputs are read from the latest deployment: adding or renaming a Start input and redeploying updates the custom block automatically; overrides for deleted inputs are ignored.

### Outputs \[#outputs]

Choose the values consumers can reference, grouped by their source block and output path. Expose at least one and at most 50 outputs. Each needs a unique name of up to 60 characters; `success`, `error`, and `cost` are reserved.

Review exposed output paths when you change the source workflow. Redeployment updates execution but does not author a new output interface for you.

### Trace policy \[#trace-policy]

**Trace runs in consumer logs** is off by default. The source workflow still has its own execution log; its internal trace is omitted from the consumer's log. Consumers with independent source-workspace access can still read logs there.

Warning:

Enabling consumer tracing exposes source block names, inputs, outputs, and prompts to anyone authorized to read the consuming workflow's logs, including people without source-workspace access. Review the data the source can handle before enabling it.

Changing the trace policy applies to future runs; it does not rewrite earlier logs. Failures return a reference ID so the publisher can find the source run while nested error details remain redacted for consumers.

## Use a custom block \[#use-a-custom-block]

Open the workflow builder's toolbar and find **Custom Blocks**. Drag a published block into the workflow, fill its inputs, and reference its named outputs downstream. Availability is subject to [permission groups](/platform/enterprise/access-control).

The source workflow's owner supplies personal variables and delegated calls. Its workspace supplies workspace variables and carries billing. Consumer inputs cross that boundary; consumers do not acquire the owner's credentials or source-workspace access. Review inputs and exposed outputs as the block's public interface.

Run a representative consumer workflow after publishing. Verify the required inputs, selected outputs, trace visibility, and source run in Logs.

## Update, disable, or delete a block \[#update-disable-or-delete-a-block]

Open the block under **Settings → Workspace → Custom blocks**. Blocks from other source workspaces are visible for organization reuse; managing them requires admin access to their source workspace.

- Edit the name, description, icon, input overrides, outputs, or trace policy. Editing the publication does not change the source workflow.
- To change execution, edit and redeploy the source. Every consumer then uses that deployment; there is no version pin or separate republish step.
- Setting the publication's `enabled` field to `false` through the API hides it from new selections and makes existing placements unavailable at execution. Set it to `true` to restore availability. This is separate from disabling a placed canvas block.
- Deleting permanently removes the publication. Existing placements remain in consumer workflows and fail because their custom block is missing.

Warning:

Replace custom-block placements in affected drafts and deployments before deleting. The usage warning includes both. Deletion does not rewrite consumer graphs or delete the source workflow.

Undeploying the source makes the block unavailable until the source is deployed again. Deleting the source workflow also removes its publication and leaves consumer placements broken. To switch to another source, publish that workflow as a new block and replace old placements before removing the old publication.

## Related docs \[#related-docs]

- [Workflow deployment](/workflows/deployment)
- [Permission groups](/platform/enterprise/access-control)
- [Execution logs](/logs-debugging/logging)