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

# Build Workflows

> Design Altostrat SDX workflows with triggers, actions, conditions, variables, testing, and execution logs.

Workflows are visual automation graphs. A trigger starts the run, actions perform work, conditions branch the path, and logs show what happened at each node.

Use workflows when you need repeatable operational logic that spans SDX services, external systems, notifications, scripts, policies, tags, reports, or data transformation.

## Prerequisites

Before you build a workflow, make sure you have:

* Permission to view and create workflows.
* A workflow authorization for actions that call SDX on behalf of a user.
* Vault secrets for any external API credentials, tokens, passwords, or signing keys.
* A sample payload or test context for the event you expect the workflow to handle.

## The Workflow Shape

```mermaid theme={null}
flowchart LR
  Trigger["Trigger"] --> Condition{"Condition"}
  Condition -->|true| ActionA["Action"]
  Condition -->|false| ActionB["Action"]
  ActionA --> Logs["Run logs"]
  ActionB --> Logs
```

Every workflow should answer four questions:

1. What starts it?
2. What context does it receive?
3. What decisions does it make?
4. What side effects can it create?

## Build A Workflow

<Steps>
  <Step title="Create the workflow">
    Go to **Automation**, open **Workflows**, then create a workflow. Give it a name and description that explain the operational intent, not just the implementation.
  </Step>

  <Step title="Add a trigger">
    Choose the trigger that matches the source event. For example, use a scheduled trigger for recurring checks, a WAN trigger for failover events, or an API trigger when an external system needs a response.
  </Step>

  <Step title="Add actions">
    Add nodes that perform the work. Common actions include Altostrat API calls, notifications, tag updates, WAN priority updates, external webhook calls, data transforms, and MikroTik script execution.
  </Step>

  <Step title="Add conditions">
    Use conditions when the workflow should branch based on status, tags, numbers, dates, booleans, arrays, or switch cases.
  </Step>

  <Step title="Test nodes">
    Test nodes with representative input. A node test is most useful when the context matches the event shape the workflow will receive in production.
  </Step>

  <Step title="Activate and monitor">
    Activate the workflow only after the graph, authorization, and secrets are correct. Watch the first real run and inspect logs for each node.
  </Step>
</Steps>

## Passing Data Between Nodes

Workflow nodes can use output from earlier nodes as variables in later node fields. Use this for things like:

* Passing a `site_id` from a site trigger into a **Get Site** action.
* Using a WAN tunnel ID from a WAN event in a **Get WAN Tunnel** action.
* Sending transformed text into a notification.
* Mapping an external payload into the exact shape another API expects.

Keep variable paths readable. If a payload is complex, use **JSON Parser**, **Data Mapper**, or **Text Transform** nodes to normalize the shape before later actions depend on it.

## Design Patterns

<CardGroup cols={2}>
  <Card title="Event response" icon="radio">
    Start from a platform event, enrich it with site or WAN data, then notify the right group or create an external ticket.
  </Card>

  <Card title="Scheduled audit" icon="calendar-clock">
    Run on a schedule, fetch site state, filter by tags or conditions, and produce a notification or report artifact.
  </Card>

  <Card title="Reusable subflow" icon="waypoints">
    Put common logic in a workflow-triggered workflow, then call it from multiple parent workflows.
  </Card>

  <Card title="Guarded change" icon="shield-check">
    Check tags, policy state, or service status before making a network-changing call.
  </Card>
</CardGroup>

## Validation And Loops

SDX validates workflow structure before saving. Workflows that trigger other workflows cannot create circular dependencies, and a workflow cannot trigger itself.

For lists, use **Loop / Iterator** carefully. Keep the loop body small, constrain the item list, and make downstream actions idempotent so a retried run does not duplicate work.

## Related Pages

<CardGroup cols={2}>
  <Card title="Workflow triggers" icon="play" href="./triggers-and-webhooks" arrow="true">
    Compare trigger types and event sources.
  </Card>

  <Card title="Node reference" icon="boxes" href="./node-reference" arrow="true">
    Review the current trigger, action, condition, and loop node catalog.
  </Card>
</CardGroup>