Workflow Orchestration Markup Language

If you can read HTML, you can use WOML to automate anything, literally anything.

WOML is an open, executable format for durable workflow applications. Write workflow structure like HTML, use JavaScript whenever you need real logic, and run it anywhere—with reliable execution, deployment, inspection, control, and recovery built in.

$ curl -fsSL https://woml.org/install | bash

$ npm install --global woml-cli

$ bun add --global woml-cli

$ pnpm add --global woml-cli

What WOML is

Workflow applications as readable documents.

WOML is an HTML-inspired language and self-hosted runtime for durable automation. Open a .woml file and its triggers, steps, decisions, approvals, and execution policy read from top to bottom. Run that same file and WOML turns it into an operational workflow backed by real JavaScript and a durable engine.

The source is not an export of the workflow. It is the workflow.

How WOML works

From readable workflow to durable execution.

Write the structure in a .woml file, start it from a trigger or command, and let WOML execute each step while preserving the decisions and results needed to inspect, control, and continue the run.

workflow.womlWriting workflow

TerminalWaiting for source

The document you write is the workflow WOML validates, activates, and executes.

The idea in one file

The graph gets crowded. The source stays clear.

A visual builder looks clean in the demo and turns into spaghetti in production. The same workflow in WOML is just text, linear, searchable, and diffable no matter how big it gets. Growth adds lines to a file, not tangles to a canvas.

process-order.womlwriting WOML

<woml>
  <workflow id="process-order">
    <triggers>
      <webhook id="order" path="/orders" auth="none" />
    </triggers>
    <steps>
      <step id="normalize">
        <script>return { total: context.payload.total };</script>
      </step>
      <parallel id="checks">
        <step id="stock">
          <script>return { available: true };</script>
        </step>
        <step id="risk">
          <script>return true;</script>
        </step>
        <step id="fraud">
          <script>return { clear: true };</script>
        </step>
      </parallel>
      <choose id="route">
        <when test="{{context.steps.risk}}">
          <step id="fulfill">
            <script>return { status: "accepted" };</script>
          </step>
          <result value="{{context.steps.fulfill}}" />
        </when>
        <otherwise>
          <step id="reject">
            <script>return { status: "rejected" };</script>
          </step>
          <result value="{{context.steps.reject}}" />
        </otherwise>
      </choose>
      <parallel id="aftercare">
        <step id="notify">
          <script>return { sent: true };</script>
        </step>
        <step id="audit">
          <script>return { recorded: true };</script>
        </step>
        <step id="metrics">
          <script>return { counted: true };</script>
        </step>
      </parallel>
      <step id="finish">
        <script>return context.steps.route;</script>
      </step>
      <fork id="distribution" join="all">
        <branch id="emailLane">
          <step id="emailReceipt">
            <script>return { queued: true };</script>
          </step>
          <step id="trackEmail">
            <script>return { tracked: true };</script>
          </step>
        </branch>
        <branch id="warehouseLane">
          <step id="reserveShipment">
            <script>return { reserved: true };</script>
          </step>
          <step id="updateInventory">
            <script>return { updated: true };</script>
          </step>
        </branch>
        <branch id="analyticsLane">
          <step id="publishMetric">
            <script>return { published: true };</script>
          </step>
          <step id="archiveOrder">
            <script>return { archived: true };</script>
          </step>
        </branch>
      </fork>
    </steps>
  </workflow>
</woml>

LinearSearchableDiffable

Visual workflow builderWaiting for workflow structure

With every node, readability drops and maintenance multiplies.

Beyond the connector catalog

Your workflow shouldn't stop at “integration unavailable.”

Sooner or later, every no-code platform tells you "not supported" and your automation stops at the edge of someone else's roadmap. WOML has no edge. Any API, any library, any custom logic becomes a capability you define yourself and call like it shipped with the tool. Your workflow's limits are yours, not the platform's.

local module · explicit import

<woml>
  <imports>
    <module name="googleMaps" from="./google-maps.ts" />
  </imports>

  <workflow id="locate-delivery">
    <triggers>
      <webhook
        id="delivery"
        path="/deliveries"
        method="POST"
        auth="bearer"
        secret="{{secrets.WEBHOOK_TOKEN}}"
      />
    </triggers>

    <steps>
      <step id="normalize">
        <script>
          return { address: context.payload.address.trim() };
        </script>
      </step>

      <step id="geocode">
        <script>
          return services.googleMaps.geocode(
            context.steps.normalize.address,
            secrets.GOOGLE_MAPS_API_KEY
          );
        </script>
      </step>

      <step id="result">
        <script>return context.steps.geocode;</script>
      </step>
    </steps>
  </workflow>
</woml>

Visual workflow builderChoose the next node

Search integrations

Google Maps isn't available yet.

Request this integration and wait for a future release. We'll notify you when it's ready.

Waiting for the platform

Only available integrations become nodes. Google Maps never reaches the canvas, while the WOML files beside it already contain the missing capability.

In this workflow, google-maps.ts becomes services.googleMaps. The source names the dependency, the graph keeps its vertical sequence, and the third step no longer depends on someone else's integration roadmap.

Not just a syntax

One file. The whole workflow system.

WOML keeps the definition, execution, and operation of a workflow connected. Describe it once in a readable .woml file, then let the engine run it and the runtime give you the controls to operate it reliably.

Source of truthWOML

One readable, executable definition.

01Describe
Readable language
Describe workflow structure like a document. Use JavaScript wherever the logic needs real code.
02Execute
Durable engine
Execute the same file as a reliable workflow application—not as a diagram or static configuration.
03Operate
Operational runtime
Deploy, inspect, control, and recover workflows through a runtime that understands their definition.

One file, many responsibilities

The same artifact remains useful from the first idea to production operation.

ProgramWhat executes
Architecture diagramHow work connects
Automation configurationWhat the workflow needs
Execution policyHow it runs
DocumentationWhat people understand
Shared artifactWhat developers and AI agents create, review, and run

The diagram, the code, the configuration, and the production workflow never drift apart. In WOML, they are the same artifact.

Built to grow

Start with one workflow. Grow into a system.

Begin with one .woml file and one useful automation. As the work expands, add decisions, concurrent work, approvals, state, and services inside the workflow—or compose it with other WOML workflows that return results, continue independently, or react to durable events. The system gets bigger without hiding its structure.

Primary workflowcustomer-onboarding.woml

01
TriggerNew customer
02
Validate customerCheck required data
03
Parallel checksCall two workflows for results
04
Choose onboarding routeBranch from customer context
05
Wait for approvalPause for a durable decision
06
Store progressKeep durable workflow state
07
Coordinate workflowsStart work and publish an event

Call · returns resultrisk-assessment.woml

Risk score returned

Call · returns resultidentity-verification.woml

Identity result returned

Start · independentwelcome-sequence.woml

Continues on its own

Event · customer.readycrm-sync.woml

Subscriber activated

Event · customer.readycustomer-analytics.woml

Subscriber activated

Scale by adding structure when it belongs together, and new workflows when it does not.

A workflow can call another for a result, start it independently, or publish an event to multiple subscribers. Every part remains a readable .woml document.

Executable examples

See these applications take shape as readable source.

Explore complete .woml files that combine workflow structure, JavaScript, services, state, decisions, and human input.

View all examples

01.woml

<woml>
  <workflow
    id="order-fulfillment"
    name="Order fulfillment"
    description="Validate, review, and admit customer orders for fulfillment."
    version="1.0.0"
  >
    <config concurrency="20" rate-limit="300/1m" timeout="48h" queue="orders" />

    <triggers>
      <webhook
        id="newOrder"
        path="/webhooks/orders"
        method="POST"
        auth="bearer"
        secret="{{secrets.ORDER_WEBHOOK_TOKEN}}"
      >
        <schema>

BusinessParallelApproval

Orchestrate high-value order fulfillment

Validate orders, check inventory and fraud concurrently, route risky purchases to a durable human decision, and publish one auditable outcome.

View example

02.woml

<woml>
  <imports>
    <module name="supportAi" from="./support-ai.ts" />
  </imports>

  <workflow
    id="telegram-support-agent"
    name="Telegram support agent"
    description="Answer support questions and escalate sensitive cases."
    version="1.0.0"
  >
    <config concurrency="16" rate-limit="120/1m" timeout="2m" queue="support" />

    <triggers>
      <telegram
        id="supportMessage"
        events="message"
        bot-token="{{secrets.TELEGRAM_BOT_TOKEN}}"

AI agentTelegramState

Build a Telegram support agent with durable memory

Wrap an AI model with normalized messages, durable conversation memory, supervised replies, retries, and an asynchronous human escalation workflow.

View example

03.woml

<woml>
  <workflow
    id="customer-import"
    name="Customer import"
    description="Normalize and persist a batch with durable row-level progress."
    version="1.0.0"
  >
    <config concurrency="2" timeout="30m" queue="imports" />

    <triggers>
      <webhook
        id="importCustomers"
        path="/webhooks/customer-imports"
        method="POST"
        auth="bearer"
        secret="{{secrets.IMPORT_WEBHOOK_TOKEN}}"
      >
        <schema>

DataFor eachPostgreSQL

Import thousands of customers with durable per-row progress

Validate a dataset, process up to ten thousand customers with bounded concurrency, upsert valid rows, and preserve ordered results.

View example

04.woml

<woml>
  <workflow
    id="expense-compliance"
    name="Expense compliance"
    description="Apply policy and hold exceptional expenses for Finance review."
    version="1.0.0"
  >
    <config concurrency="12" timeout="72h" queue="finance" />

    <triggers>
      <webhook
        id="submitExpense"
        path="/webhooks/expenses"
        method="POST"
        auth="bearer"
        secret="{{secrets.EXPENSE_WEBHOOK_TOKEN}}"
      >
        <schema>

Human operationsApprovalStorage

Automate expense compliance without hiding the human decision

Apply deterministic expense policy, archive receipts, share one approval across providers, and publish the accounting decision.

View example

05.woml

<woml>
  <workflow
    id="payment-webhook-ledger"
    name="Payment webhook ledger"
    description="Deduplicate payment events and start the correct backend process."
    version="1.0.0"
  >
    <config concurrency="32" rate-limit="600/1m" timeout="2m" queue="payments" />

    <triggers>
      <webhook
        id="paymentEvent"
        path="/webhooks/payments"
        method="POST"
        auth="bearer"
        secret="{{secrets.PAYMENT_WEBHOOK_TOKEN}}"
      >
        <schema>

BackendWebhookIdempotency

Process payment webhooks into an idempotent ledger

Turn repeated payment deliveries into an idempotent ledger, exact event routing, and independently durable fulfillment work.

View example

06.woml

<woml>
  <imports>
    <module name="deploymentApi" from="./deployment-api.ts" />
  </imports>

  <workflow
    id="deployment-safety-gate"
    name="Deployment safety gate"
    description="Authorize, deploy, verify, and roll back application releases."
    version="1.0.0"
  >
    <config concurrency="4" timeout="2h" queue="deployments" />

    <triggers>
      <webhook
        id="releaseCandidate"
        path="/webhooks/releases"
        method="POST"

DevOpsApprovalModules

Put a durable safety gate in front of production deployments

Run parallel preflight checks, require production approval, call your infrastructure API, verify health, and roll back explicitly.

View example

07.woml

<woml>
  <imports>
    <module name="slackMessages" from="./slack-messages.ts" />
  </imports>

  <workflow
    id="omnichannel-incident-assistant"
    name="Omnichannel incident assistant"
    description="Classify and route incident reports from three chat providers."
    version="1.0.0"
  >
    <config concurrency="24" rate-limit="240/1m" timeout="2m" queue="incidents" />

    <triggers>
      <slack
        id="slackIncident"
        events="app-mention,direct-message"
        channels="incidents"

CommunicationEventsSwitch

Run one incident assistant across Slack, Telegram, and Discord

Handle Slack, Telegram, and Discord with one provider-independent incident flow and broadcast critical events to responder workflows.

View example

08.woml

<woml>
  <imports>
    <module name="contentStudio" from="./content-studio.ts" />
  </imports>

  <workflow
    id="editorial-content-pipeline"
    name="Editorial content pipeline"
    description="Research, review, publish, and archive weekday content."
    version="1.0.0"
  >
    <config concurrency="1" timeout="48h" queue="editorial" />

    <triggers>
      <schedule id="weekdayEdition" cron="0 8 * * 1-5" timezone="UTC" on-missed="skip" />
      <manual id="draftNow" />
    </triggers>

ContentAIFork

Research, approve, and distribute content from one workflow

Research and draft with AI, wait for editorial approval, then publish through independent multi-step channel branches.

View example

09.woml

<woml>
  <workflow
    id="local-operations-report"
    name="Local operations report"
    description="Build a daily report from a local SQLite database."
    version="1.0.0"
  >
    <config concurrency="1" timeout="5m" queue="local-reports" />

    <triggers>
      <manual id="buildNow" />
      <schedule id="dailyReport" cron="0 18 * * *" timezone="UTC" on-missed="run-once" />
    </triggers>

    <steps>
      <step id="loadJobs" name="Load recent jobs">
        <script>
          const db = services.db({

LocalSQLiteSchedule

Generate a local operations report with no cloud account

Query local SQLite, calculate metrics in JavaScript, generate CSV, and store a versioned report without a cloud account.

View example

10.woml

<woml>
  <workflow
    id="document-platform"
    name="Document processing platform"
    description="Route tenant documents to specialized durable processors."
    version="1.0.0"
  >
    <config concurrency="100" rate-limit="1000/1m" timeout="1m" queue="document-ingress" />

    <triggers>
      <webhook
        id="submitDocument"
        path="/webhooks/documents"
        method="POST"
        auth="bearer"
        secret="{{secrets.DOCUMENT_API_TOKEN}}"
      >
        <schema>

PlatformWorkflow callsAI

Build a multi-workflow document processing API

Expose one product endpoint and route tenant jobs to independently durable invoice, contract, and summarization workflows.

View example

11.woml

<woml>
  <workflow
    id="service-health"
    name="Service health"
    description="Check public WOML endpoints and summarize their health."
    version="1.0.0"
  >
    <config concurrency="1" timeout="2m" />

    <triggers>
      <interval id="poll" every="5m" on-missed="skip" />
    </triggers>

    <steps>
      <parallel id="checks" name="Check endpoints" concurrency="3" on-error="wait-all">
        <step id="website" name="Check woml.org" retry="3" retry-backoff="exponential">
          <script>
            const response = await services.http.request({

IntervalParallelHTTP

Monitor services in parallel

Check several live endpoints on one durable interval, then turn their individual results into one readable health report.

View example

12.woml

<woml>
  <workflow
    id="order-approval"
    name="Order approval"
    description="Hold a submitted order for an explicit human decision."
    version="1.0.0"
  >
    <config concurrency="8" timeout="48h" queue="orders" />

    <triggers>
      <webhook
        id="submitOrder"
        path="/webhooks/orders"
        method="POST"
        auth="bearer"
        secret="{{secrets.ORDER_WEBHOOK_TOKEN}}"
      >
        <schema>

WebhookApprovalDurability

Hold an order for human approval

Accept a validated order webhook, pause durably for a decision, and make the approved and rejected paths explicit.

View example

13.woml

<woml>
  <imports>
    <module name="googleMaps" from="./google-maps.ts" />
  </imports>

  <workflow
    id="geocode-address"
    name="Geocode address"
    description="Resolve a submitted address through a local Google Maps service."
    version="1.0.0"
  >
    <triggers>
      <webhook
        id="submitAddress"
        path="/webhooks/geocode"
        method="POST"
        auth="bearer"
        secret="{{secrets.GEOCODE_WEBHOOK_TOKEN}}"

Local moduleAPISecrets

Add Google Maps as a local service

Create the integration your workflow needs in TypeScript, import it as a service, and keep the orchestration readable in WOML.

View example

14.woml

<woml>
  <workflow
    id="customer-event-ledger"
    name="Customer event ledger"
    description="Record validated customer updates in SQLite."
    version="1.0.0"
  >
    <config concurrency="4" queue="customer-events" />

    <triggers>
      <event id="customerUpdated" name="customer.updated">
        <schema>
          {
            "type": "object",
            "required": ["customerId", "change"],
            "properties": {
              "customerId": { "type": "string" },
              "change": { "type": "string" }

EventsSQLiteValidation

Record customer events in SQLite

Subscribe to an internal event, validate its payload, and write an auditable record through WOML’s supervised database service.

View example

WOML vs Alternatives

Most workflow tools optimize for either visual simplicity or engineering power. WOML is designed to keep both: readable workflow structure for the whole team and real JavaScript whenever the automation needs it.

Tool	How you build workflows	Readable by the whole team	Self-hosted	Logic without a ceiling
WOML	Markup + JavaScript	✅ Clear, document-like structure	✅	✅ Inline JavaScript, modules, and services
n8n	Visual canvas	⚠️ Easy at first; harder as the canvas grows	✅	⚠️ Code and custom nodes
Zapier	Visual canvas	⚠️ Friendly for smaller automations	❌	⚠️ Platform actions and code steps
Temporal	Code with language SDKs	❌ Primarily readable by engineers	✅	✅ Full programming languages
AWS Step Functions	JSON/YAML with ASL	❌ Requires ASL and AWS knowledge	❌	⚠️ Extended through AWS services and functions
Apache Airflow	Python DAGs	❌ Primarily readable by Python/data teams	✅	✅ Python and operators

WOML's difference: it combines document-like readability, self-hosted ownership, and full JavaScript flexibility in the same workflow file.

One readable file. A durable runtime behind it.

Get started Read the documentation

If you can read HTML, you can use WOML to automate anything, literally anything.

Workflow applications as readable documents.

From readable workflow to durable execution.

The graph gets crowded. The source stays clear.

Your workflow shouldn't stop at “integration unavailable.”

One file. The whole workflow system.

Readable language

Durable engine

Operational runtime

Start with one workflow. Grow into a system.

See these applications take shape as readable source.

Orchestrate high-value order fulfillment

Build a Telegram support agent with durable memory

Import thousands of customers with durable per-row progress

Automate expense compliance without hiding the human decision

Process payment webhooks into an idempotent ledger

Put a durable safety gate in front of production deployments

Run one incident assistant across Slack, Telegram, and Discord

Research, approve, and distribute content from one workflow

Generate a local operations report with no cloud account

Build a multi-workflow document processing API

Monitor services in parallel

Hold an order for human approval

Add Google Maps as a local service

Record customer events in SQLite

WOML vs Alternatives

One readable file. A durable runtime behind it.