Live triggers are bound only for active workflows. When a matching event occurs, the plugin normally queues a run for background execution through WP-Cron. If no run appears, first confirm that the trigger can fire and that the workflow is active; then check background execution and run history.
Confirm the trigger and workflow
- Open Agent Workflows → Workflows and edit the workflow.
- Confirm the workflow is Active, not a draft or paused workflow. The trigger binder only binds workflows whose status is active.
- Confirm the selected trigger is available on this site. For example, Elementor form triggers require Elementor Pro, Contact Form 7 triggers require Contact Form 7, WPForms triggers require WPForms, and WooCommerce triggers require WooCommerce to be active.
- Review the trigger’s configuration and the fields used by downstream nodes. A trigger may receive a payload with different keys than the action expects.
Screenshot to add: [Workflow Editor trigger node configuration]
Know which kind of run you are testing
- Manual run: started from the workflow/run interface. It does not prove that a live WordPress event is bound correctly.
- Live trigger: listens for the selected WordPress or integration event. Only active workflows are bound.
- Incoming webhook: uses its own public endpoint and validation checks. If the caller receives a rejection response, use the incoming webhook troubleshooting guide.
- Background execution: queues a live-triggered run for WP-Cron when enabled. A queued run may not start until WordPress cron processing occurs.
Check background execution and run history
- Open Agent Workflows → Settings → Advanced and inspect Background execution. It is enabled by default and queues live-triggered runs through WP-Cron.
- If background execution is enabled, open Agent Workflows → Runs and look for a Queued run before concluding that the trigger never fired.
- If runs remain queued, check whether WP-Cron is running on the site and whether the hosting environment disables or delays scheduled WordPress tasks.
- If background execution is disabled, the trigger runs synchronously in the request that fired the event. Check that request’s behavior and server logs if it does not complete.
- Open a matching run and inspect its Trigger payload and Node log. A run that exists but fails is an execution or configuration problem, not necessarily a trigger-registration problem.
Check conditions and duplicate protection
The plugin includes a short trigger debounce for supported entity identifiers and guards against workflow re-entry while plugin actions are writing data. As a result, repeated saves or automated writes may be suppressed to avoid duplicate runs and feedback loops. This is not a guarantee that every external event is delivered exactly once.
Use a controlled event with a known workflow and inspect the resulting run history. If a run starts but later nodes are skipped, inspect the condition or branch node configuration and the node log; that points to workflow routing rather than a trigger that failed to start. Do not repeatedly trigger a production workflow if its actions send messages, update records, or make external requests.