15.6. Publish, Monitor, and Troubleshoot Workflows

Publishing a workflow makes it active for future events or schedules. Monitoring confirms that the workflow is doing what the business expected.

Use Workflows > Workflow Control Panel to review run status, filters, exports, and troubleshooting actions.

Figure 1: Run monitoring shows whether workflows succeeded, failed, waited, or are still running.

Drafts, published versions, and changes

Workflows should be edited as drafts and published only after validation. Publishing creates an active version that future triggers can run.

State	Meaning	Operational guidance
Draft	Work in progress.	Safe for editing; not yet the active business process.
Published	Active version used by events or schedules.	Monitor after publishing, especially for client-facing actions.
Updated draft	Proposed changes to an already published workflow.	Review and test before replacing the active version.
Paused or disabled	Temporarily stopped.	Use when troubleshooting or preventing more runs.

Use clear descriptions so future admins understand why the workflow exists and what changed between versions.

Before publishing

Check these items:

the trigger is the correct business event or schedule;
required action fields are filled;
mapped fields come from the expected trigger or step output;
branches and waits are documented in the workflow description;
client-facing emails or notifications have been reviewed;
secrets and credentials are configured by an authorized admin;
the workflow has a clear owner;
the team knows how to pause or roll back if needed.

Reading run status

Status	What it usually means	What to do
Succeeded	The workflow completed.	Spot-check early runs to confirm business results.
Running	The workflow is actively processing.	Wait briefly, then investigate if it remains running unexpectedly.
Waiting	The workflow is paused for a time wait, event wait, or retry.	Confirm the wait is expected and tied to the business process.
Failed	A step errored and the workflow could not complete.	Open the run details, review the failing step, fix configuration or data, then retry if appropriate.
Canceled	A user or system stopped the run.	Confirm cancellation was intentional.

Troubleshooting workflow issues

Symptom	What to check
Workflow did not start	Confirm the workflow is published, the trigger event happened after publishing, and the event matches the selected category/event.
Workflow started too often	Add conditions, narrow the trigger, or check whether a workflow action is causing another triggering event.
Action failed because data was missing	Review required fields and field mappings for the failed step.
Email or notification did not send	Check recipients, email settings, provider configuration, and failure logs.
Workflow is waiting longer than expected	Review wait step settings, event correlation, and expected business timing.
Duplicate work was created	Confirm idempotency settings, trigger scope, and whether multiple workflows respond to the same event.

Retry, resume, and replay

Depending on the failure and permissions, admins may be able to retry, resume, or replay a workflow run.

Action	Use it when	Caution
Retry	A transient issue occurred, such as a temporary provider failure.	Confirm the step is safe to run again.
Resume	A waiting or blocked run can continue after the issue is resolved.	Confirm the business state has not changed unexpectedly.
Replay	You need to rerun from prior input for investigation or correction.	Avoid replaying client-facing or billing-impacting actions without review.
Cancel	A run should stop and not continue.	Document why the run was canceled if it affects client operations.

Dead letter and blocked runs

A dead-letter or blocked-run view is where failed or unprocessable work can be investigated. Use it when a workflow event or run cannot proceed normally.

Common causes include:

invalid or incomplete input data;
missing workflow version;
a workflow waiting for an event that never arrives;
permissions or secret problems;
repeated action failures.

Treat dead-letter review like an operations queue. Assign an owner, resolve the root cause, then retry or close the item according to your internal process.

First-week monitoring plan

For every new published workflow:

Check run history after the first expected trigger.
Review at least one successful run step by step.
Review any failed or waiting runs.
Ask the business owner whether the automation produced the expected result.
Adjust the draft and republish if needed.
After confidence is established, reduce monitoring to normal operational review.

Navigation