F
Flowman docsWorkflow SDK
Back to app
All docs

Organize workflows

Every workflow now belongs to a single project. Use categories to group them on the workflows page, and use visibility to share or keep them private.

Categories

Categories are project-scoped labels. Open the Categoriespanel from the workflows page header to add, rename, or remove them. Workflows that aren't assigned to a category appear under Uncategorized.

  • Set a category when registering a workflow (New Workflow modal) or change it later from the "..." menu on each workflow card.
  • Categories linked to workflows cannot be removed. Move those workflows to another category or Uncategorized first.
  • Section open/closed state is remembered per project so users return to the same layout.

Duplicating workflows

Choose Duplicate workflow from a workflow card menu to create a private, visible snapshot in the same project and category. The copy keeps the description, icon, version, route, parameters, and coding-page visibility, but it does not copy existing runs.

  • Copies are named Workflow Copy, Workflow Copy 2, and so on, with matching -copy slug suffixes.
  • Duplicates are always private even when the source is a public template. Publish the copy explicitly after reviewing it.
  • Duplication requires project-admin access and fails without creating a partial record if the source no longer exists or a unique slug cannot be allocated.

Coding Agent workflow templates

Use New Workflow on the workflows page to create a project-scoped workflow derived from the registered Coding Agent workflow. The new workflow copies the Coding Agent route and parameters, then stores default values and visibility choices on its own workflow record.

  • Hidden fields are still submitted when the workflow starts, so a workflow such as Plan New Feature can expose only the repository and prompt while defaulting runtime environment, branch mode, model, reasoning, speed, and plan mode.
  • Use the pencil action on a Coding Agent child workflow to edit its name, slug, description, category, public/private visibility, exposed fields, and saved defaults. The slug is the workflowSlug used by the HTTP API; changing it does not rewrite existing runs.
  • Required fields cannot be hidden unless they have a valid default. Attachments cannot be saved as defaults because uploads are tied to a specific run.
  • Runs are recorded under the child workflow's slug and card even though the request posts to the shared Coding Agent route. Flowman validates that the selected workflow belongs to the project and that its route matches the request route before opening the run.
  • Use Prompt templateon the child workflow editor to wrap the user's run prompt with a master template. Include {prompt} where the user's text should appear. The merged prompt is what the coding agent receives and what is stored on the run.
  • Enable hidden Design mode for PRD workflows. Design-mode runs still use plan mode and clarification questions, but the ready artifact is reviewed as a PRD and finalized without implementation.

Prompt templates

Project prompt templates live under Build → Prompts. Create reusable prompts there with placeholders like {topic} or {audience}. When starting a workflow that has a required string parameter named prompt, the run modal shows Build prompt. The drawer lets you pick a saved template, fill its placeholder values, preview the final prompt, copy it, and apply it to the workflow's normal prompt input. On the Prompts page, Generate opens the same drawer for that template so you can fill placeholders and copy the final text without starting a run.

This is separate from a child workflow's hidden promptTemplate field, which wraps {prompt} automatically when the run starts. Project templates help users compose the prompt field; workflow prompt templates combine that text with a fixed master prompt at runtime.

Blank placeholder values become empty strings in the transformed prompt. Applying a built prompt does not change the workflow route or runtime contract; the final text is still sent as record.input.prompt.

Public templates

Marking a workflow as Public template keeps it inside its owning project, but exposes it under Browse templates for users in other projects. Copying a template creates a fresh, project-scoped workflow in the target project. The copy is a one-time snapshot — there is no ongoing link to the source.

  • Switch visibility from the workflow card menu (Publish as public template / Make private) or from New Workflow.
  • Copies inherit name, description, icon, version, route, and parameters from the source.
  • Coding Agent templates also ensure the target project has its own base coding-agent workflow so the child can be edited and used as a template source. New projects get that base at creation time.
  • Workflow slugs are unique per project. If the source slug already exists in the target project, the copy gets a -copy (then -copy-2, ...) suffix automatically.

Privacy

Private workflows are invisible from Browse templates and cannot be copied by users outside the owning project. Use this for internal-only automations or work-in-progress workflows.