Skip to main content

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.

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

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

1

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.
2

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.
3

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.
4

Add conditions

Use conditions when the workflow should branch based on status, tags, numbers, dates, booleans, arrays, or switch cases.
5

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.
6

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.

​
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

Event response

Start from a platform event, enrich it with site or WAN data, then notify the right group or create an external ticket.

Scheduled audit

Run on a schedule, fetch site state, filter by tags or conditions, and produce a notification or report artifact.

Reusable subflow

Put common logic in a workflow-triggered workflow, then call it from multiple parent workflows.

Guarded change

Check tags, policy state, or service status before making a network-changing call.

​
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.

Workflow triggers

Compare trigger types and event sources.

Node reference

Review the current trigger, action, condition, and loop node catalog.