Running & Managing Workflows

Building a workflow's rules is only half the job — this article covers everything that happens after: running it, managing multiple rules and workflows over time, and re-running a workflow against submissions that already existed before it was built.

Running a workflow

This is the step people miss. Saving a workflow does not make it start running on its own. Every workflow in this release uses a manual, on-demand trigger — it only processes submissions when someone actually clicks Run. It doesn't run continuously in the background, on a schedule, or the instant a new submission comes in. This gives you direct control over exactly when automation fires, but it also means a workflow you never click Run on will never do anything. Build "click Run" into your team's regular routine (e.g., daily, or right after each intake deadline) until scheduled triggers are available in a future release.

Before running a workflow for the first time (or after editing it), it's worth a final check of:

Every rule's Live Preview, to confirm the logic reads the way you intend
That any hidden fields your actions reference (Set Field Value, Total & Set Field Value) actually exist and are correctly hidden from submitters
That any Send Email actions have a complete, correctly-addressed email before running

The Run flow, step by step

Click Run next to a workflow in the Workflows list. This opens a Run dialog specific to that workflow, where you'll confirm two things before anything happens:

Step 1: Confirm the Program year. This defaults to the workflow's configured cycle year, but you can change it here if you need to run the same workflow logic against a different year.

Step 2: Choose what this run should apply to:

All submissions — runs the workflow against every submission it applies to for that program year. This is the option you'll use most of the time, including the first time you run a newly built workflow.
A specific submission — runs the workflow against just one submission, identified by its ID. This is the one to reach for when you're testing a rule you just built, or double-checking why a particular submission didn't get tagged/emailed/routed the way you expected — without touching every other submission in the program.

Step 3: Preview or run. You have two buttons:

Preview: Shows you exactly what would change, for every affected submission, without actually applying anything. Nothing is saved.
Run now: Actually applies the workflow. This is the point at which tags get added, emails get sent, fields get set, and so on.

Tip: Get in the habit of hitting Preview before Run now, especially the first time you run a new or recently-edited workflow, or after using A specific submission to debug one case. Preview costs nothing to check and catches a misconfigured condition or action before it actually sends an email or changes real submission data.

Managing rules within a workflow

From a workflow's Rules screen, you'll see every rule listed with quick-reference badges — for example, "1 condition · Tag Submission" — so you can tell at a glance what each rule does without opening it.

Edit: Reopens the rule builder for that rule, with everything you've configured already in place.
Delete: Permanently removes the rule from the workflow. This can't be undone, so double-check before confirming.

Reordering rules

Rules run in order, top to bottom. If a workflow has more than one rule, drag the handle (⠿) next to a rule to move it up or down in the list.

Order matters most in two situations:

When multiple rules could match the same submission. Since each rule runs independently in sequence, whichever rule runs first "sees" the submission's state as it was at that point — including any changes an earlier rule already made (like a tag or field value another rule set).
When you're chaining logic across rules — for example, Rule 1 sets an eligibility field, and Rule 2's condition checks that same field. Rule 1 needs to run before Rule 2 for this to work as intended.

Note: Rule edits and reordering take effect the next time you click Run on the workflow — they don't retroactively change anything from a run that already happened.

Re-running a workflow on existing submissions

Workflows aren't limited to only affecting submissions going forward — you can run a workflow retroactively against submissions that already existed before the workflow was built. This is especially useful right after you've finished building a new workflow, and want it to apply to your current backlog rather than only future submissions.

To do this, click Run on the workflow, choose All submissions, and (optionally) hit Preview first to see what will change before committing. This evaluates every eligible submission against the workflow's rules, exactly as if each one had just triggered the workflow for the first time.

If you only want to catch up a single submission rather than the whole backlog, use A specific submission in the same Run dialog instead.

Note: Built-in safeguards still apply on a re-run — duplicate-prevention means actions that already ran successfully for a submission (like a tag that's already present, or an email that's already been sent with "Send only once per submission" on) won't run again. See Understanding Execution Logs & Troubleshooting Workflows for how this shows up in the log.

Managing multiple workflows

The Workflows list (Applications tab) shows every workflow for the program, with:

Name — the workflow's name, along with a badge showing its program cycle year
Created By — which admin built it, and when it was created
Last Run — when it was last triggered, or "Never" if it hasn't been run yet
Actions — a Run button to open the Run dialog described above, plus a ⋮ (kebab) menu with Edit and Execution Logs

Use Quick Search and the Year filter to narrow this list down once you have several workflows across program cycles — searches match on workflow name.

What's next

Understanding Execution Logs & Troubleshooting Workflows — see exactly what happened the last time a workflow ran, submission by submission.