Gate97Workflows, triggers & actions
A workflow starts at exactly one trigger step and branches out from there on a visual canvas — drag steps into place and draw a connection from one to the next. Any step can connect to more than one next step, and every step can use data from any step before it on its own path.
Trigger steps
The trigger is always step zero — what starts the workflow. Every trigger runs in one of three modes:
- Polling — Gate97 checks the connected app roughly every 60 seconds for anything new (a new row, a new issue, a new order). Most triggers work this way.
- Webhook — the provider calls Gate97 the instant the event happens. Currently only Stripe's Payment Event trigger works this way; see Webhooks for how to wire it up.
- Manual — no polling, no webhook. You start the run yourself with a click from the dashboard, optionally pasting in a JSON payload to test against. Useful for workflows you want to trigger on demand rather than automatically.
A workflow only starts running once it's activated. Activating a polling trigger begins its 60-second checks; activating a webhook trigger registers a unique, unguessable URL for that step. Deactivating stops both — nothing is deleted, it just stops firing.
Any polling or webhook trigger can also run in batch mode — collecting records instead of firing a run for each one, then relaying them together on a schedule or condition, with its own reporting dashboard. See Batch Collection & Reports.
Action steps
Each action step calls one operation on a connected app — send a Slack message, create a record, update a ticket, and so on. If a step has more than one step connected after it, all of them run; if it fails, only the steps on its own path afterward are skipped — any other, unrelated branch keeps going.
Filter steps
A filter step checks one field against a value and routes the run down one of two paths: connect steps to its <b>Yes</b> output for what should happen when it matches, and to its <b>No</b> output for what should happen when it doesn't. Leave either side unconnected and that path simply does nothing. The available checks are equals, not_equals, contains, exists, and not_exists. For example, a filter on {{trigger.status}} equals paid can send a receipt down the Yes path and a payment-failed alert down the No path, from the very same event.
Branching and multiple paths
Connect a step to more than one next step and all of them run — useful for, say, posting to Slack and updating a spreadsheet from the same event, independently of each other. A filter step's Yes and No outputs work the same way, just conditionally.
Drag the + button under any step to add a new, already-connected step; drag an existing step to reposition it anywhere on the canvas; select a connection and delete it to disconnect two steps.
Mapping data between steps
Any text field in a step's configuration can reference an earlier step's output using {{ }} template syntax:
{{trigger.fieldName}}— a field from the trigger step's output.{{step1.fieldName}},{{step2.fieldName}}, etc. — a field from the output of the step you added Nth. This numbering is set once, when the step is created, and never changes based on where it sits on the canvas or how it's connected.
Exactly what fields are available depends on what the earlier step's connector returns — use Test this step on the earlier step first to see its real output shape before referencing it further down the workflow.
Testing a step
Every step has a Test this step button. It runs that one step for real, right now, against the real connected app (or, for a trigger step, against a JSON payload you provide), and shows the real response or error — the same code path a live run uses, so what you see here is what will actually happen once the workflow is active.
Run history
Every time a trigger fires, a run is created and appears in that workflow's Run History — whether it succeeded, failed, or was stopped by a filter, along with each step's real input and output. This is the first place to look when a workflow isn't doing what you expect.