# Workflow Builder Configuration
URL: /workflow-builder-configuration
Type: howto
Description: Configure workflow blocks in Stylo by selecting a node, setting its fields, inserting variables, and defining structured schema or JSON where needed.
Keywords: workflow builder, blocks, configuration, variables, schema
After you place a block on the workflow canvas, you configure it from the panel on the right side of the editor. Use this panel to choose the block type, connect the right integration, set field values, and pass data from earlier steps into later ones.

{/* TODO(docs): screenshot — Workflow Builder with a selected node and the configuration panel open. Tracked in public/images/README.md. */}

Open the configuration panel [#open-the-configuration-panel]

Select any node on the canvas to open its configuration.

The panel can show:

* The current block name
* The node label
* The block type selector
* Required configuration fields for that block
* Integration selection when the block needs connected credentials

If no block type is set yet, Stylo prompts you to choose one before the node can be fully configured.

Set the block type and label [#set-the-block-type-and-label]

Each node has two different identifiers in practice:

* **Block type** defines what the node does
* **Label** is the name you see on the canvas

Change the block type when you want the node to perform a different action. Change the label when you want a clearer name for the step in your workflow.

For trigger nodes, the configuration panel includes a trigger type picker so you can switch between supported trigger blocks directly.

Connect the right integration [#connect-the-right-integration]

Some blocks depend on a connected integration before they can run.

When a block requires an integration, the configuration panel shows an integration picker for that provider. This lets you choose which connected account the block should use.

If the required integration is not connected, the block configuration may remain incomplete until that connection exists.

Fill in block fields [#fill-in-block-fields]

Stylo renders block fields based on the block’s configuration schema.

Depending on the block, fields may appear as:

* Short text inputs
* Long text areas
* Dropdowns
* Toggles
* Sliders and number inputs
* Template-aware fields
* Structured JSON builders
* Structured schema builders

Required fields are marked in the panel, so you can see which settings must be completed before the block is ready.

Use template variables in fields [#use-template-variables-in-fields]

Some fields support template-style references to data from earlier steps.

When a field supports variable insertion, Stylo can help you insert:

* Outputs from upstream nodes
* Nested output paths from prior steps
* Built-in date and time values

The variable picker is scoped to upstream nodes, which helps prevent you from referencing a step that does not feed into the current node.

{/* TODO(docs): GIF — inserting an upstream variable into a template-enabled field. Tracked in public/images/README.md. */}

Pin output shapes from a test run [#pin-output-shapes-from-a-test-run]

Dynamic blocks — webhooks, AI outputs, API calls — don't declare their full output structure upfront. The variable picker learns those fields from test runs, but a run can fall out of recent history, and a brand-new workflow has no runs at all. Pinning solves that.

After a successful test run, Stylo automatically records each node's output structure (the field names and their types — not the actual values) on the workflow. Those pinned fields stay available in the variable picker from then on, even if the run itself is no longer in the recent history list.

You can also pin or unpin a node's shape manually:

* In the execution terminal, select a step whose output you want to keep available.
* In the output panel header, click **Pin shape** to freeze it, or **Unpin** to remove it.
* A small pin indicator appears on the node in the canvas when a shape is pinned.

Pinning captures the structure only — no sample values are stored on the workflow. When a field's path comes from a pinned shape, the variable picker labels it **Pinned from prior run** so you can tell it apart from fields declared by the block itself.

Use workflow variables [#use-workflow-variables]

Workflow-level variables can also be referenced in node configuration.

These are useful when:

* The same value should be reused across several blocks
* You want one place to update a shared constant
* A workflow needs structured default data that multiple steps depend on

For example, you might use workflow variables for routing values, repeated messages, or default JSON payload fragments.

Use the schema builder [#use-the-schema-builder]

Some blocks need a structured schema instead of a single value.

The schema builder lets you define fields with supported types such as:

* `string`
* `number`
* `boolean`
* `array`
* `object`
* `enum`

You can also:

* Mark fields as optional
* Define nested fields for objects
* Define item types for arrays
* Upload a JSON file to replace the current schema

This is useful when a block needs a predictable output structure or a structured contract for downstream steps.

Use the JSON builder [#use-the-json-builder]

Some blocks expect raw JSON configuration.

The JSON builder supports two editing styles:

* **Builder mode** for editing fields visually
* **Raw mode** for editing the JSON directly

Use the builder when you want a safer visual editor. Use raw mode when you already have the JSON structure you want and prefer to paste or edit it directly.

Use large text editors for prompts and templates [#use-large-text-editors-for-prompts-and-templates]

Longer text fields can be expanded into a larger editing surface.

This is especially useful for:

* AI prompts
* Instructions
* Templated messages
* Large structured text values

If a field supports templating, the larger editor keeps that variable-insertion behavior available while giving you more room to work.

Structured outputs and downstream references [#structured-outputs-and-downstream-references]

Configuration choices affect what later nodes can reference.

For example:

* Declared block outputs become available to later steps
* Schema-builder fields can create nested output paths that later template fields can insert
* Cleaner node labels make output references easier to recognize in the variable picker

This means configuration is not just about making one node valid. It also shapes how easy the rest of the workflow is to build.

Recommended configuration workflow [#recommended-configuration-workflow]

Use this order when configuring a new node:

1. Select the node and confirm the block type.
2. Rename the node label so the step is easy to recognize later.
3. Choose the correct integration if the block needs one.
4. Fill in required fields first.
5. Add template variables or workflow variables where values should come from other steps.
6. Use schema or JSON builders only when the block expects structured data.
7. Test or review the workflow after configuration changes.

Related [#related]

* [Workflow Builder Overview](/workflow-builder-overview) for the broader automation-builder layout and concepts
* [Workflow Testing and Execution History](/response-workflows/testing-and-history) for testing and reviewing workflow behavior