Community

A workflow is private to its organization until you list it in the community. Listing one makes its published versions readable by anyone — signed in or not — at its permanent address, and lets other people fork it into an organization of their own.

What "public" means

Visibility is a property of the workflow, and it applies only to what you have already published. Two consequences follow:

• You must publish a version before you can list a workflow. The community reads immutable workflowVersion snapshots, so a workflow with nothing published has nothing to show.
• Your working copy stays private. The editor's draft — the thing autosave and the workflow agent write to — is never served publicly. Visitors see the version you deliberately pinned, and nothing you have changed since.

Nothing else about your organization becomes visible: runs, costs, comments, members, balances, and API keys are all unaffected.

What is visible is the full graph of every published version, including node settings, prompts, and constant values. Treat a listed workflow as published source: don't leave anything in a const node you wouldn't put in a README.

Listing and withdrawing

In the Studio editor, open Share in the left rail, add a short description, and choose Publish to community. The workflow then appears in the Studio's Community section and at its public page:

https://studio.blitflow.com/w/<org-slug>/<workflow-slug>

That URL is the workflow's published address, so it is permanent. A ?v= query pins the page to one version — ?v=1.2.0 for an exact semver, ?v=1 for that major's highest — using the same selectors as the API. Without it the page follows @latest, including after a rollback.

Make private takes the listing and the public page offline again. Existing forks are independent copies and keep working; the slug stays claimed, so re-listing later restores the same address.

Inspecting

The public page renders the published graph read-only: pan and zoom the canvas, switch versions, and read the workflow's derived interface — its inputs, their types and which are required, and its named outputs. This is the same interface the API exposes, so it tells you exactly what you would be calling.

You cannot run a workflow from its public page. A run spends an organization's balance, so running one means forking it into an organization of yours first.

Forking

Fork copies the version you are looking at into an organization you choose:

• The copy is seeded from the pinned published version, not the original's working copy.
• It starts as an ordinary private draft — no claimed slug, no version history, not listed. Published names belong to the organization that claimed them, so your fork claims its own on its first publish.
• It records where it came from. The editor shows the source address beside the workflow name, and the original's public page counts its forks.

From there it is your workflow: edit it, run it, and publish it under your own name. The original is untouched, and later versions of it do not flow into your fork.

You need an account to fork, and write access (admin or member) in the organization you fork into.