Skip to content
ARGUS User Manual

Workflows

Admin → Workflows (/admin/workflows) is the no-code automation builder. Each workflow binds one or more triggers (events) to a set of actions, filtered by conditions. Workflows run on the argus-api worker and can post to chat, drive a dock, spawn a flight task, or chain another workflow.

Requires admin or superadmin. The engine is in active development — the pages below describe what ships today plus what is staged behind validation but not yet enabled at runtime; flagged where relevant.

The list

Two view modes — a compact card list and a DAG canvas (toggle in the header). Per-workflow the list shows:

  • Name, description.
  • Enabled / paused state.
  • Trigger count and action count.
  • Most recent run status.
  • Per-mission override badge (when present).

Header shows {workflowCount} total and {enabledCount} active.

Triggers

From WORKFLOW_TRIGGER_TYPES, grouped exactly as the builder groups them:

  • Flights — flight.started, flight.completed, flight.failed.
  • Alerts — alert.cas, alert.geofence, alert.hms, geofence.enter, geofence.exit.
  • AI / Media — detection.new, media.captured.
  • Docks — dock.online, dock.offline.
  • Operations — operation.created, operation.started, operation.completed.
  • Sensors — battery.low, weather.threshold, timeWindow.weather.
  • Schedule — schedule.cron, schedule.interval.
  • External — webhook.received, manual.
  • Composite (aspirational) — workflow.completed, workflow.failed, compound (AND/OR of triggers).

This set is a superset of the webhook event list — anything you can subscribe a webhook to, you can also trigger a workflow on.

Conditions

Conditions are payload filters evaluated after the trigger fires. A condition is {leftPath} {operator} {rightValue} where leftPath is a JSONPath into the event payload.

Operators from CONDITION_OPERATORS:

OperatorLabel
eq / neq= / ≠
gt / gte> / ≥
lt / lte< / ≤
contains / not_containsstring or array membership
regexfull RegExp match

Conditions combine with AND at the top level. Use condition action branches for OR.

Actions

From WORKFLOW_ACTION_TYPES, grouped by category:

Notifications

  • Send Webhook (one-shot POST), Send Email (Handlebars templates), Send Slack (Block Kit), Send SMS (Twilio), Copilot Alert (CAS-style master-caution banner into a mission HUD).

Drone / Dock

  • Launch Mission (from a template, optionally on a specific dock), Fly Route (waypoint mission), Return Dock Home, Open / Close Dock Cover, Capture Photo/Video, Upload Media (dock → S3), Download Telemetry.

Imagery / AI

  • Run Mapping (2D/3D), Change Detection, Generate Report (early-fires the AI mission-report pipeline), Run AI Detection.

Streaming

  • Start / Stop Stream Forward — relay a TACLINK stream to an external RTMP / SRT.

Operations

  • Create Map Flag — drop a pin. Update Task Status.

Data / Code (aspirational for most orgs)

  • Firestore Read / Write, HTTP Call, Execute Script (V8 sandbox, Sovereign only), Transform Data (JSONata).

Flow control

  • Delay, Branch / If-Else (condition), Parallel, Wait For Condition, Human Approval (approval_gate), Loop, On Failure (branch_on_failure).

Templates

The Templates drawer hosts ready-made workflows — “HMS Critical → Slack + RTH”, “Detection watchlist hit → Copilot alert”, “Mission complete → Generate report + email team”. Pick one and the builder pre-fills trigger, conditions, and actions.

Per-mission override

Workflows apply org-wide by default but can be overridden per-mission. On the mission settings tile an admin sees every enabled org workflow as a toggle and can disable specific ones for that mission only. Overrides are stored on the mission doc and never modify the org-level workflow.

Runs, versions, metrics

  • Live validation — the builder flags missing required fields, invalid cron, unreachable branches, and role-policy conflicts. Save is disabled while errors exist.
  • Runs — chronological executions with step status, payload snapshot, and error detail.
  • Versions — every save is a new version; roll back from the list.
  • Metrics — success rate, median duration, and cost estimate (30 d).
  • Audits — who created, edited, enabled, or disabled the workflow.
  • Role policies — map WorkflowActionType → allowed roles, enforced before each action runs.