Triggers & activation

A workflow is active or inactive. Active means its triggers fire against the pinned snapshot; inactive means nothing runs unless you click run on the canvas. Every workflow starts from exactly one kind of trigger step, found under Start in the Blocks palette. There are nine.

Webhook

The webhook step gives you a unique URL under /webhooks/… with a per-webhook bearer token (or HMAC signing). POST a JSON body to fire the workflow; the payload becomes the trigger step's output, with the caller's JSON under payload.body. Response mode decides what the caller gets back: immediate (202 at once), last_step (wait for the run and return the final output) or respond_step (a respond to webhook step crafts the reply).

The same step also has an App event source: pick a connected app (Slack, GitHub) and its events start the workflow with no URL at all. See the webhook step.

While building, put the webhook into listening mode and send a real request from the source system. MadMax captures the payload and uses it as the sample every downstream step verifies against.

Schedule

Cron-style schedules (*/15 * * * *) with a timezone, DST included. The schedule fires only while the workflow is active, and always against the pinned snapshot, so edits after activation don't change what runs until you publish them. Plans cap how often a schedule can fire and how many scheduled workflows can be active at once; the activation gate tells you when you're over. See schedule.

Watch

A poll: on a cron schedule the step calls a connected app's list or search operation, remembers what it has seen (deduped by a unique field such as id), and runs the workflow once per new item. The first poll records a baseline without firing, so activating doesn't flood on a backlog. See watch.

Email trigger

The step mints its own address (wf-…@in.madmax.build). Mail from an allowed sender whose domain passes SPF/DKIM/DMARC starts the workflow with the subject, text, html and attachments as payload. See email trigger and email.

Text trigger

Text the platform number from a phone verified in Settings → messaging and the workflow runs with your message as payload. There is nothing to configure on the step. See text trigger.

Form

A hosted web form at a public URL; each submission fires the workflow with one payload key per field. Fields are text, textarea, email, number, dropdown, date or file. See form.

File upload

A public upload page that accepts documents (PDF and images by default, with a per-file size cap) and fires with payload.files, a list of file descriptors ready for an extract step or a loop. See file upload.

Manual

No auto-firing trigger at all: the workflow runs when you click run. Active workflows run their snapshot; add draft: true on an API run (or run an inactive workflow from the canvas) to exercise the live canvas instead. See manual.

Sub-workflow

Makes the workflow callable from another workflow's call workflow step. Internal only, no external URL; Pass payload through decides whether the caller's inputs reach the next step. See sub-workflow.

Activation gates

Activate (the topbar off / live switch) refuses politely when the graph isn't runnable yet:

• no trigger step at all (a manual trigger counts)
• steps with missing required config or connections
• broken references to steps that don't exist or aren't upstream
• expression errors in a step's config
• a call workflow step that targets this same workflow
• schedules tighter than the plan allows, or more active schedules than the plan allows across the workspace

Fix what it names and activate again. Deactivating stops triggers immediately: a webhook URL answers 404, schedules don't run, and other workflows can't call it. The snapshot stays for audit and re-activation is one click.

Related

• Activation and snapshots
• Testing: capturing real trigger samples
• Runs
• Webhooks