---
id: publishing
title: "Publish a flow as a plugin"
summary: "Turn a flow into a reusable component - a Plugin port for the request, a response type, your own configuration fields - publish it with the Publish flow dialog, and use, update or delete it in other flows."
audience: user
keywords: "publish, plugin, flow as plugin, plugin port, entry point, plugin port response, version, latest version, toolbox, category, configuration, reuse"
---
# Publish a flow as a plugin

Build a piece of logic once as a flow and use it in other flows as a single component. A published flow appears in
the toolbox next to the built-in plugins, with its own name, icon, category and configuration fields. Typical uses: a
"Create customer" step that wraps several API calls, a lookup against a reference system, a company-wide way to send
notifications.

## How it works

The flow you publish starts at a [Plugin port](/documentation/plugins/flow/entry-point) component.

- What a calling flow sends to the published component's **`Input`** pin comes out of the Plugin port's **`Request`**
  pin.
- What your flow sends to the Plugin port's **`Response`** pin, or to a
  [Plugin port response](/documentation/plugins/flow/entry-point-response) component, comes out of the published component's
  **`Output`** pin in the calling flow.

The call is synchronous: the calling component waits until your flow has sent the response. Each request is answered
once.

```text
Calling flow:   Http listener → [Create customer] → Http response

Published flow: Plugin port (Request) → Data mapper → Http client → Data mapper → Plugin port (Response)
```

## Build the flow

1. **Give the flow its own namespace.** A published flow can't use the default namespace `viauser`. Pick one that
   names your organisation and area, such as `Acme.Crm`.
2. **Add one Plugin port.** A flow can be published with exactly one.
3. **Connect the request.** Connect the Plugin port's `Request` pin to the first component of your logic. The type on
   this connection becomes the type of the published component's `Input` pin.
4. **Send the response.** Connect the end of your logic to the Plugin port's `Response` pin. When the answer is
   produced in several places, for example in a success branch and an error branch, place a **Plugin port response**
   component in each place instead of drawing every connection back to the Plugin port. All responses must use the
   same type; it becomes the type of the `Output` pin.
5. **Add configuration fields.** Every property you add to the flow's configuration becomes a field of the published
   plugin, with the same name, type, default value and validation. When a calling flow starts, the values set on the
   component are copied into these properties, so your flow reads them like any other flow setting.
6. **Describe it.** The flow's **Description** becomes the plugin's description in the toolbox.

A Plugin port only emits requests when the flow runs as a plugin inside another flow. To test it, publish it and call
it from a small test flow.

## Publish

Open the flow and click **Publish flow** in the designer toolbar. The flow is validated first; fix any errors it
reports. The **Publish flow** dialog has four pages:

| Page | Fields |
|---|---|
| **Plugin** | **Plugin name**, the name in the toolbox. **Config name**, the name of the configuration class generated from your flow's configuration properties, or **No config** when the plugin has no fields of its own. **Package name**, the name of the built assembly. **Category**, the toolbox group the plugin appears in. **Major**, **Minor**, **Build** and **Revision version**. |
| **Types** | The flow types other flows may use once the plugin is installed, for example the types of the request and response fields. |
| **Vendor** | **Name**, **Author** and **Email**, shown in the plugin information. |
| **Icon** | An SVG file dropped onto the page, one of the **Predefined icons**, or SVG source pasted in. Without one, the plugin gets a default icon. |

Click **Publish**. Viaducta compiles the flow in release mode, packs it with its types and dependencies, and adds it
to the plugin repository. Every designer of your tenant gets the plugin in its toolbox at once, under the category
you chose, and the plugin is available in all environments of the tenant.

The dialog remembers what you entered, so the next publish of the same flow starts with the same values.

## Use it

Drag the plugin from the toolbox into a flow like any other component. Connect its `Input` and `Output` pins, and fill
in its configuration fields; expression settings and bindings work as for every other component.

## Update it

Change the flow and publish it again with a higher version. The new version replaces the old one in the toolbox, and
earlier versions stay in the plugin repository.

Each component chooses which version it runs, in the **Version** row of its properties:

- **Always use latest version of the plugin**: the component runs the newest version each time its flow is compiled
  and started. New components get this setting while the flow's **Use latest plugin versions (auto update)** option is
  on, which is the default.
- **Always use specific version of the plugin**: the component stays on the version you pick from the list.

A running flow picks up a new version the next time it is started.

## Delete it

Plugins published by your tenant show a delete icon in the toolbox. Deleting removes every version of the plugin,
including the versions flows still use, so check first that no flow needs it.

## Things to know

- **No timeout.** A request your flow never answers produces no output on the calling side. Make sure every path
  ends in a response, or in an error that goes back to the caller.
- **Push events to the caller.** A record that reaches the Plugin port's `Response` pin without a request, for example
  from a Timer inside the published flow, comes out of the caller's `Output` pin with fresh metadata. Use this for
  plugins that report events on their own.
- **Metadata.** The published flow gets new metadata for each request, with the caller's correlation and session id.
  The response returns to the caller with the caller's original metadata.
- **Other ways to combine flows.** [Start flow](/documentation/plugins/flow/start-flow) starts another flow without passing data, and
  [Pipe client](/documentation/plugins/pipes/port-client) / [Pipe listener](/documentation/plugins/pipes/port-listener) send records to a flow that
  is already running. See [Flows calling flows](/documentation/architecture/runtime#flows-calling-flows).