Workflow editor basics: build, test, and publish

The workflow editor is where you build an automation. The mental model is simple: a workflow is one trigger plus a chain of actions. The trigger decides when the workflow runs (a new post, a signal, a schedule, a webhook); the actions decide what happens (enrich a lead, write copy, push to your CRM, notify Slack, and so on). This article covers building, testing, and shipping a workflow.

The canvas

The editor is a visual canvas. You start from a trigger node, then add action nodes beneath it. The + between any two nodes lets you insert an action mid-chain. Select any node to configure its inputs in the left sidebar.

The toolbar on the canvas gives you Add note, Add film, Undo, Redo, Fit view, and Test workflow.

Passing data between nodes (variables)

This is the power feature. Every node produces named output variables, and later nodes can reference them. For example, a Person Enrichment node outputs an email, which you can drop into the “To” field of a Send Email node.

References use this syntax:

{{ !ref($.steps.<stepId>.result.<field>) }}

For trigger outputs, the path is $.trigger.outputs.<field>. The editor helps you insert these without typing them by hand.

When a workflow isn’t producing what you expect, it’s almost always a variable reference pointing at the wrong field. Check the source node’s outputs and make sure the path matches exactly.

Draft, Published, and Enabled — three different things

These get conflated constantly. They are separate states:

State	What it means
Draft	Your in-progress edits. Saved automatically as you work, but not live.
Published	You’ve shipped the workflow. The published version is what actually runs.
Enabled / Disabled	The toggle that controls whether the live workflow runs at all. A published workflow that’s disabled won’t fire.

If a published workflow shows an Unpublished Changes badge, it means you’ve edited the draft since publishing. Customers still get the old published version until you publish again.

Testing before you publish

Always test first. The Test flow dry-runs your workflow against real or mock data. It needs a trigger selected and at least one action configured — otherwise it’s disabled with a reason.

New Post / Multi Post triggers — test against a real post from the attached saved search.
Scheduled trigger — runs an immediate test that pulls its own data.
Webhook trigger — supply a sample JSON payload.
Signal Created trigger — test against a selected or mock signal.

Publishing

Click Publish Workflow. Trigify validates every node’s configuration, saves a version snapshot (so you can roll back), and makes the new version live. Before publishing, you’ll see a credit-cost estimate projecting your likely weekly and monthly spend based on your run volume.

Most action credit costs are fixed, but enrichment is where credits add up — and some actions cost more than others. Filter your leads before enriching so you only spend credits on the records that qualify.

Version history

Every publish snapshots a version. Open Version history to view past versions (read-only) and revert to a previous one with Back to Live.