Skip to content
  • There are no suggestions because the search field is empty.

Understanding Execution Logs & Troubleshooting Workflows

Every workflow run is recorded, submission by submission, so you can confirm your rules behaved the way you expected — and quickly diagnose it when they didn't. This article covers how to read that log, what the built-in safeguards mean in practice, and how to work through the most common "why didn't this run" situations.

Where to find the execution log

From the Workflows list, click the ⋮ (kebab) menu next to a workflow and select Execution Logs. Each submission that a workflow touches has an execution log entry recorded against it. For every run, the log captures:

  • Trigger — what started the workflow (currently, an admin clicking Run)
  • Conditions met — which of the rule's conditions were evaluated, and whether the submission matched
  • Actions executed — which actions ran as a result
  • Success / failure status — whether each action completed, was skipped, or failed, with a reason

You can check this on a per-submission basis to answer questions like "did this submission get tagged?" or "why didn't this email go out?"

Reading common log outcomes

What you'll see What it means
Warning — Email field empty, email skipped The Send Email action needed an address from a form field, but that field was blank on this submission. No email was sent for this submission; other submissions in the same run were unaffected.
Notice — Tag already exists, tag skipped A Tag Submission action tried to add a tag the submission already has. No duplicate was created — this is expected, safe behavior, not an error.
Notice — Status already set, action skipped An action tried to set a value (field, phase, etc.) that was already set to the same target. The action was skipped because there was nothing to change.
Error — Action failed Something prevented an action from completing. The error is logged, and — importantly — the workflow continues to the next action rather than stopping entirely. One failed action won't block the rest of the rule from running.

Multiple workflows on the same event

If more than one workflow could apply to the same submission and event, they execute in the order the workflows were created — not a configurable priority, so if execution order across workflows matters for your setup, keep that creation-order behavior in mind when planning which workflow to build first.

Built-in safeguards, explained

The Workflow Engine has a few protections designed in from the start, so automation can't spiral or duplicate itself:

  • Loop prevention. If a workflow is triggered by a status or action change, it will not retrigger itself as a result of the change it just made. This prevents a rule like "if status changes, then change status" from firing endlessly.
  • Duplicate prevention. The same action won't run twice for the same submission and event. This is why re-running a workflow doesn't re-tag submissions that are already tagged, or re-send emails that already went out (when "Send only once per submission" is on).
  • Concurrency handling. The system is built to safely handle multiple workflows firing at the same time without one interfering with another.

These safeguards mean it's generally safe to manually re-run a workflow — you won't create duplicate tags, repeat emails, or double-file follow-ups just by running it again.

Troubleshooting: "My workflow didn't do what I expected"

Work through these in order:

  1. Did you actually click Run? Saving or editing a workflow doesn't make it process submissions on its own — this is the single most common reason a workflow "does nothing." Go to the Workflows list and confirm you've clicked Run (and selected the right Program year and submission scope) since your last change.

  2. Check the Live Preview on the rule, not just your memory of it. It's easy to build a condition that's more (or less) restrictive than intended, especially with AND/OR logic across multiple filter groups. Reopen the rule and read the Live Preview carefully — does it actually say what you meant?

  3. Check the execution log for the specific submission. This tells you definitively whether the rule ran, whether conditions matched, and whether each action succeeded, was skipped, or failed — rather than guessing.

  4. If conditions "met" says no, check the field values on that submission directly. A common cause is a mismatch between what a condition expects and what's actually stored — for example, a condition checking for "Final" when the field's actual stored value has different casing or wording than you assumed.

  5. If an action was skipped, check the reason in the log. Skips are usually expected safeguard behavior (duplicate prevention, already-set values) rather than a problem — but if the skip reason is "field empty" and you expected data there, check the submission's actual form responses.

  6. If the submission was edited after it was originally submitted, remember workflows don't auto re-evaluate on edits. The engine treats submitted data as final at the time of submission. An edited submission won't automatically retrigger a workflow unless a specific re-evaluation trigger was built for that case — you may need to manually re-run the workflow to pick up the change.

  7. If multiple workflows touch the same submission, check execution order. Since workflows run in creation order, confirm the one you expect to "win" (e.g., set a field a later workflow depends on) was actually created first. 

What's next

If you've worked through this and a workflow still isn't behaving as expected, it's worth reviewing the rule from scratch against Building Rules: Conditions, Logic & the Otherwise Branch and the relevant action article (see Choosing a Workflow Action) for the action in question — most issues trace back to a condition or action configuration detail rather than a system problem.