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

# WooCommerce Workflow Editor

> Configure how WooCommerce bookings flow into Helm with event filters, conditions, simulation, and publish controls

Use the WooCommerce workflow editor to decide which booking events Helm processes and how they turn into Helm bookings. Every WooCommerce connection has its own workflow, and Helm keeps the published version live while you safely edit the next draft.

## Open the editor

Open your WooCommerce connection in Helm and select **Workflow**.

The editor has four working areas:

* **Canvas** — The current workflow graph
* **Nodes** — Drag new nodes onto the canvas
* **Settings panel** — Configuration for the selected node
* **Test Console** — Simulation tools for the current draft

## Drafts, versions, and publishing

* Every change auto-saves to a draft
* Incoming bookings keep using the published version until you publish
* **Discard changes** restores the last published version
* Every publish creates the next workflow version
* **Publish & update future runs** republishes the workflow and reprocesses future bookings through the new live version

<Info>
  **Run Simulation** uses the current draft, not the currently published
  version. This lets you validate changes before they go live.
</Info>

## Choose which events start the workflow

Select the **Booking Event** node to choose which events should run the workflow:

* **Booking Created**
* **Booking Updated**
* **Booking Cancelled**

Only selected events run the workflow. Unchecked events are acknowledged and ignored.

## Add conditions and branches

Use a **Condition** node when different bookings should follow different paths.

Conditions can read from three sources:

* **Payload** — Raw WooCommerce fields from the incoming event
* **Mapped** — Fields after your workflow mapping
* **Resolved** — Helm-side values available at runtime, such as the matched experience, whether that experience is active, or its tags

You can combine multiple rules with **Match all** or **Match any**, then connect the **Match** and **No match** outputs to different nodes on the canvas.

## Use End nodes to skip cleanly

An **End** node stops processing for that branch. The event is still acknowledged, but Helm does not create or update a booking.

Rename the node to describe why the flow stops. That label appears in sync logs and in simulation results, which makes skipped bookings easier to understand later.

## Test the current draft

<Steps>
  <Step title="Open the Test Console">
    Click **Simulate Run** from the workflow header.
  </Step>

  <Step title="Choose a booking payload">
    Pick a recent booking from the dropdown so Helm can use a real WooCommerce payload.
  </Step>

  <Step title="Run the simulation">
    Click **Run Simulation** to preview what the current draft would do.
  </Step>

  <Step title="Review the result">
    Check the booking outcome, warnings, branch taken, and debug data before you publish.
  </Step>
</Steps>

Simulation never writes data. It only shows what the current draft would do if that event arrived right now.

## Example: stop bookings for inactive WooCommerce products

A common setup is to let WooCommerce control whether a product is live, then stop bookings in Helm when the matched experience is no longer active.

<Steps>
  <Step title="Keep product status in sync">
    Make sure the WooCommerce product has synced recently so Helm knows whether the matching experience is active.
  </Step>

  <Step title="Add a condition before booking creation">
    Place a **Condition** node on the main path before **Create Booking**.
  </Step>

  <Step title="Check whether the experience is active">
    In the condition editor, choose the guided resolved field **Experience is active** and leave it set to `is true`.
  </Step>

  <Step title="Route inactive products to End">
    Connect the **Match** path to the next booking step. Connect **No match** to an **End** node renamed something like `Experience disabled in WooCommerce`.
  </Step>

  <Step title="Publish the workflow">
    Publish the draft so the new branch becomes live.
  </Step>
</Steps>

<Note>
  WooCommerce product status updates control the matching Helm experience:
  published products stay active, while draft, pending, and private products are
  disabled.
</Note>

## A safe edit cycle

1. Make your changes in the draft workflow.
2. Use **Run Simulation** with a real booking payload.
3. Review the publish recap.
4. Publish when the outcome matches what you expect.
5. Use **Publish & update future runs** if upcoming bookings should be reprocessed through the new workflow.