Automation and AI Run Issues
Fix workflow, AI Worker, and automation runs that do not start or fail midway.
Use this checklist when a workflow, AI Worker, or automation did not run as expected.
Start from the run record whenever possible. A run gives you the source record, trigger, status, failed step, and output, which is stronger evidence than guessing from the workflow builder alone.
Run Did Not Start
Check that the workflow or worker is active, the trigger event happened, trigger conditions match the record, required modules are enabled, and permissions allow the run to access the record.
Also confirm the record is in the workspace where the automation is configured. Similar records in another workspace, imported test records, or archived records may not satisfy the trigger you expected.
For workflows, also confirm the trigger type matches the event you expected. A manual workflow will not start from a record change, a webhook workflow will not start until the external request arrives, and a scheduled workflow depends on the configured schedule.
For AI Workers, confirm the worker is active and the source record belongs to a module the worker can read.
If the event happened in a different workspace, with an archived record, or before the automation was activated, the run may correctly not exist. Confirm the exact event time and record before changing the automation.
Run Failed
Open run history or run detail. Failures often come from missing required fields, deleted records, disconnected integrations, expired credentials, permission limits, invalid configuration, or AI Worker tool/context restrictions.
Read the first failed step before rerunning. Later steps may be skipped because an earlier action did not produce the expected record, variable, or integration response.
Capture the run ID, failed step, input record, error text, and integration status before editing the workflow. This gives you a before-and-after trail when the fix is tested.
AI Worker Output Is Poor
Review worker instructions, context sources, allowed tools, and run history. Add clearer instructions or enable the required context/tool category.
Good fixes are specific. Instead of adding broad instructions, state the exact records the worker should read, the fields it should update, the tone it should use, and the conditions where it should stop or ask for review.
If the output is risky, pause the worker before editing. Re-enable it only after one safe run proves the new instructions, context, and tools produce usable results.
Rerun Safely
Before rerunning an automation:
- Confirm whether the previous run already created records, sent emails, or changed statuses.
- Fix the failed configuration, missing field, or disconnected integration.
- Test with one record when possible.
- Review the new run detail before enabling broad automation again.
Never rerun blindly when the previous attempt may have sent email, created an invoice, changed a customer record, or called an external app. Clean up or account for the previous side effect first.
Duplicate Or Partial Results
If an automation created duplicate tasks, comments, emails, invoices, or status changes, pause the automation before investigating. Then identify whether the duplicate came from multiple triggers, a manual rerun, a delayed run resuming later, or an external app sending the same event more than once.
For partial results, keep the records that were correctly created and only fix the missing or incorrect part. Deleting everything and rerunning can make the audit trail harder to follow.
Evidence To Capture
When reporting an automation issue, capture:
- Workflow or worker name.
- Run ID or timestamp.
- Source record link.
- Trigger type.
- Failed step name.
- Error message.
- Integration status if an external app was involved.
This information helps an admin fix the exact configuration instead of changing unrelated automation settings.