Join the LadVen OS testing programRequest a demo
Skip to main content

Run history and troubleshooting

Run history answers the main automation-control question: did the rule, robot, or workflow fire, and if not — why. Without it, you can't tell whether automation is actually working or silently sitting idle. This page is about how to read run results and troubleshoot common problems.

History lives in the same place as each engine: for task rules — on the "History" tab, and for CRM robots and workflows — in their own sections.

Where to look at history​

  • task rules — the "History" tab on /tasks/automation: run records per task;
  • CRM robots — run history per deal in CRM automation;
  • workflows — step history in the instance card and the "due steps to run" summary;
  • deferred steps — run summary: how many were processed, succeeded, and failed.

Start troubleshooting with the engine whose behavior surprised you, and open its history for the specific object.

What a history record shows​

Each history record describes one run:

  • status — how the run ended;
  • time — when it fired or was scheduled;
  • object — the task or deal the run applied to;
  • reason — a code/explanation if the run did not execute;
  • message — the error or result text.

The "status + reason" pairing is the main troubleshooting tool: the status tells you what happened, the reason — why.

Run outcomes​

A run ends with one of these outcomes:

  • succeeded — the action was performed;
  • skipped — a condition was not met or the run was not allowed, so the action was not applied;
  • failed — the action should have run but couldn't;
  • blocked — an operation guard stopped the operation.

Skipped and blocked are not malfunctions but expected behavior by the rules; a failure is what needs troubleshooting.

Why a rule was skipped​

"Skipped" usually means the run didn't match by conditions or permissions:

  • the rule conditions were not met for this object;
  • the scope does not include this project, pipeline, or stage;
  • the assignee or the rule lacks permissions for the required action.

This is normal: the rule deliberately leaves alone anything outside its conditions. If it should have fired — the conditions or scope are too narrow or incorrect.

Why a run was blocked​

"Blocked" means an operation guard fired: the operation did not pass because a required condition was not met (for example, an empty field before a stage change). This is not an automation error but an enforced policy. Troubleshoot it by the guard message: it explains what you need to fill in or complete.

Why a step failed​

"Failed" means the action should have run but couldn't. Common reasons: the action assignee lacks permissions, the required participant or object is missing, the action is configured incorrectly, or an external operation is unavailable (for example, sending an email without an active template). Look at the record message — it points to the specific reason.

Partial result​

For robots and "due steps to run" runs a partial result is possible: part of the chain or part of the deferred steps ran, part did not. For a robot this depends on the error policy (stop or continue), and for a run it is visible in the summary (processed/succeeded/failed). A partial result is more dangerous than a full failure: the object is left in a half-processed state, so such records should be troubleshooted first.

Common fixes​

  • skipped when it should have fired — check the conditions and scope;
  • blocked — satisfy the operation guard requirement or adjust the guard itself;
  • permissions error — grant permissions to the action assignee or change the assignee;
  • email-sending error — make sure the template is active and the variables are correct;
  • a recurring error on the same step — fix the rule, robot, or workflow template, not the object by hand.

Good practices​

  • Review history regularly, not only when something breaks.
  • Distinguish the routine "skipped/blocked" from a real "failed".
  • Troubleshoot partial results first.
  • Fix the cause in the automation setup, not the symptom by hand.
  • Treat recurring errors as a signal to revisit the rule or workflow.

Common mistakes​

Treating "skipped" as a breakdown. Most often the rule deliberately leaves alone an object outside its conditions.

Fixing the object by hand instead of the cause. The error will recur on the next run.

Ignoring a partial result. The object is left in an inconsistent state.

Not reading the message and reason. They point directly to what to fix.

How to confirm you fixed it​

  • a repeat run (or a manual run) ends with success;
  • the history record shows the expected status with no errors;
  • blocked runs disappear after the guard requirement is met;
  • partial results are carried through to completion, and the object is in a correct state;
  • the recurring error no longer appears in history.