Testing Workflows

FlowMint has no dry run that executes steps without their effects. Testing is two stages: validate the definition, then run it for real against a submission you make yourself, while the workflow is not yet serving visitors.

What validation checks

flowmint_test_workflow (REST: POST /workflows/{id}/test) returns valid, errors and warnings. It checks the definition’s shape: the trigger, step names, step types, on_error values, file steps after an entry delete, and entry data in a scheduled workflow.

It does not run any step, fill in any placeholder, check a step’s settings, check the steps inside conditional or try_catch, or confirm that the form exists. A workflow that passes can still fail on its first run.

Validation needs a saved workflow. Pass a new config to check a change before you save it, or none to check what is stored. Include the trigger block in a config you pass.

How to test a form workflow

1. Create the workflow with enabled set to false. Saving checks that the form exists, which validation alone does not.
2. Run flowmint_test_workflow and fix every error.
3. Enable the workflow. From now on every stored submission of that form runs it, so on a live site do this when a test submission is the next one you expect, or test on a copy of the form or a staging site first.
4. Submit the form yourself with realistic values: a file in each file field the workflow uses, and each option a condition tests. You can also ask the assistant to submit it with the Promptless Forms connector’s test submission; a dry run does not store an entry, so it does not start a workflow, and a connector submission carries no files.
5. Open the run in FlowMint Workflows → Run History and check each step’s status and output.
6. Ask the assistant to fetch the run (flowmint_get_run). Each step’s config_snapshot holds the config it actually ran with, placeholders filled in, so you can see the real recipient, subject and URL. Blank values there mean a path did not resolve.
7. Check the result where it lands: the inbox, the Drive folder, the Printavo quote, the records.

Fix and repeat

Change the workflow, then replay the run instead of submitting again: a replay runs the current definition against the same entry. Replays repeat side effects, so clean up test quotes, folders and records as you go.

Test a scheduled workflow

A scheduled workflow has no “run now”. Its first run comes at the next scheduled time (an hour after saving for hourly). To run it sooner, open Tools → Scheduled Actions (on a WooCommerce site, WooCommerce → Status → Scheduled Actions), search for fmw_scheduled_workflow_tick, find the pending action whose arguments hold your workflow id, and choose Run. The next regular run keeps its time. After one run exists you can replay it as often as you need.

Limits and common problems

• Placeholders you cannot trigger by hand. A condition on a rare value is tested only when you submit that value. Submit once per branch.
• Test runs send real email. Use your own address in the fields a workflow emails to, or add a skip_if while you test.
• Validation passes, the save fails. The form id does not exist on this site. Create the form first.

Related pages

• Your First Workflow — Build a workflow that emails your office when a contact form is submitted, test it, turn it on, and confirm the run in Run History.
• Viewing Runs — Find a run in FlowMint Workflows → Run History, read its status and each step's output or error, and know what the record keeps and for how long.
• Replaying Runs — Run a finished run again after fixing what made it fail, what a replay repeats, and what you cannot do to a run that is still queued or running.
• Connector Overview — The 16 FlowMint connector tools grouped by task, the permission they need, the REST API behind them, and what an assistant cannot do through them.