> ## Documentation Index
> Fetch the complete documentation index at: https://learn.workflow.dog/llms.txt
> Use this file to discover all available pages before exploring further.

# Use Meta Controls

> Gate, order, observe, and debug any action without changing its core behavior.

Meta Controls add execution inputs and diagnostic outputs to an action. Select
one node and open **Meta Controls** from its selection toolbar or configuration
panel.

They are available independently of the action's package, so the same control
patterns work across integrations and built-in actions.

## Available controls

| Meta Control            | Adds                         | Behavior                                                 |
| ----------------------- | ---------------------------- | -------------------------------------------------------- |
| **Conditional**         | **Condition** input          | Runs the action only when the connected value is truthy. |
| **Wait For**            | **Wait For** input           | Delays the action until the connected output emits.      |
| **Did Action Attempt?** | **Attempted?** output        | Reports whether the action itself was invoked.           |
| **Did Action Succeed?** | **Succeeded?** output        | Reports whether it ran without an error.                 |
| **Error**               | **Error** output             | Exposes the action's error message when it fails.        |
| **Outputs As Object**   | **Outputs As Object** output | Collects all ordinary action outputs into one object.    |

Turning off a control removes its handle and any connection attached to that
handle.

## Run an action conditionally

Enable **Conditional** and connect a condition to **Condition**:

```text theme={null}
Is order total greater than 500?
  → Condition on "Notify reviewer"
```

When the condition is falsy, the action is not attempted. Its ordinary outputs
emit no signal, so nodes that depend on them do not run.

This differs from an action that runs successfully and returns `null`: a
`null` result is still a value, while a skipped action produces no ordinary
output signal.

Use [Route Value](/reference/actions/control/demux) instead when both the true
and false paths should perform visible work. See
[Branch Workflows](/building/branching) for the choice between gating and
routing.

## Add an ordering dependency

Connections normally carry both data and execution order. Sometimes one action
must wait for another even though it does not need the earlier action's value.

Enable **Wait For** and connect any output from the prerequisite:

```text theme={null}
Create customer ── output ──→ Wait For on "Send welcome email"
email address ──────────────→ To on "Send welcome email"
```

The connected output's value is not passed into the action's ordinary inputs.
It only establishes that the output must emit first.

<Warning>
  Wait For requires an emitted value. If the upstream node is disabled, skipped,
  fails, or takes an unselected routing path, the waiting action is not
  attempted.
</Warning>

## Observe whether an action ran

**Attempted?** and **Succeeded?** answer different questions:

| Outcome                                                                  | Attempted? | Succeeded? |
| ------------------------------------------------------------------------ | ---------- | ---------- |
| Action completed successfully                                            | `true`     | `true`     |
| Action ran and threw an error                                            | `true`     | `false`    |
| Action was disabled, skipped by a condition, or lacked a required signal | `false`    | `false`    |

These status outputs are useful for reporting and cleanup paths that must
distinguish “did not run” from “ran and failed.”

Because meta-control outputs are settled even when ordinary outputs are not,
they can drive downstream diagnostics after a failure or skip.

## Capture an error message

Enable **Error** to expose the formatted error from the action:

* a failed action emits its error message;
* a successful attempted action emits `null`; and
* an action that was not attempted emits no error value.

Pair it with the status outputs when the distinction matters:

```text theme={null}
External action
  ├─ Attempted? ─┐
  ├─ Succeeded? ─┼─ Create Object ─ Log result
  └─ Error ──────┘
```

<Note>
  Exposing **Error** does not turn a failed action into a successful one or
  retry it. It makes failure data available for diagnostic paths.
</Note>

## Collect outputs for inspection

**Outputs As Object** bundles the action's ordinary returned outputs into one
Object. It is primarily useful for:

* inspecting a node with many outputs;
* passing a complete result into a log or sub-workflow; or
* capturing a snapshot while debugging.

On success, the object contains the outputs returned by the action. When the
action does not produce results, it emits `null`.

Prefer named output handles for long-lived production connections. They make
dependencies explicit and avoid coupling downstream nodes to every field the
action returns.

## Disable nodes temporarily

Disabling is a selection action rather than a Meta Control, but it participates
in the same execution semantics. Select one or more nodes and choose
**Disable**; choose **Enable** to restore them. Disabled nodes are not
attempted, and their ordinary outputs emit no signal.

On macOS, the shortcut is `⌘ ⇧ E`.

Use disabling to isolate part of a workflow during development. Before
shipping, check every downstream dependency: disabling a producer can skip
more than the selected node.

## Debug a branch deliberately

For an action whose execution is unclear, temporarily enable:

1. **Did Action Attempt?**
2. **Did Action Succeed?**
3. **Error**
4. **Outputs As Object**

Run representative true, false, successful, and failing cases. The four
outputs reveal whether the action was eligible, whether it completed, why it
failed, and what it returned. Remove diagnostic controls you no longer need so
the production graph keeps a clear contract.