Sooner or later a user will tell you that a task never appeared, an email went out twice, or a field changed on its own. Workflow problems are frustrating because the symptom shows up in one place while the cause sits somewhere else entirely. A calm, repeatable routine will solve most of them faster than guessing.

Recognize the Three Basic Failure Types

Almost every workflow complaint falls into one of three categories, and naming the category narrows your search immediately.

1. It did not run. The expected outcome never happened.
2. It ran when it should not have, or more than once. Duplicates, spurious alerts or loops.
3. It ran but did the wrong thing. The wrong value, the wrong owner or the wrong recipient.

Ask the reporter for one specific example record, the time it happened and what they expected. A real record is worth more than any description.

Step One: Reproduce or Locate the Evidence

Open the example record and read its activity history and field history if your platform keeps them. Look for what changed, when, and by whom or what. Many systems label automated changes separately from manual ones, which tells you quickly whether the workflow touched the record at all.

If your platform offers execution logs for automation, check whether the rule was evaluated and what it concluded. Check the vendor’s current documentation for where those logs live and how long they are kept, as this varies widely.

Step Two: Check the Usual Suspects

Experience shows that a short list of causes explains most failures.

Symptom	Common causes	What to check
Did not run	Rule inactive, condition not met, record created by a method that skips automation	Rule status, exact condition values, how the record was created
Ran twice	Two overlapping rules, a loop caused by its own update	Other rules on the same object, re-evaluation settings
Wrong value	Field mapped incorrectly, rule order, a later rule overwriting	Order of execution, field mappings
Wrong person notified	Owner field empty or outdated, role changed	Assignment logic, user status
Stopped after working	Field or picklist value renamed or deleted, user deactivated	Recent configuration changes

Conditions deserve special attention. A rule that checks for the stage value “Qualified” will quietly stop working if someone renames that stage to “Sales Qualified”. The rule has not broken; the world changed under it.

Step Three: Look for Interactions

Workflows rarely live alone. A newer rule may conflict with an older one, a validation rule may block an automated update, or an integration may write to the same field a few seconds later. When a result seems illogical, list every rule, integration and import that can touch the affected field. The culprit is often the one nobody thought to mention.

Timing also matters. If two processes act on the same record at nearly the same moment, the final value can depend on which finishes last.

Step Four: Fix Safely

Resist the urge to edit the live rule immediately. A safer sequence looks like this:

• Document the current configuration, even with simple screenshots or notes.
• Make the change in a sandbox or on a copy if possible.
• Test the expected case, the failing case and a nearby case that should be unaffected.
• Deploy at a quiet time and watch the first few executions.
• Record what changed and why in the workflow’s description.

If the workflow has already produced bad data, plan the cleanup separately. Fixing the rule does not repair the records it damaged, so identify which records were affected, using a report filtered by date and value, and correct them in a controlled batch.

Prevent the Next Incident

Most recurring workflow problems come from change without communication. Introduce a light habit: before anyone renames a picklist value, deletes a field or deactivates a user, they check which rules reference it. Keeping a simple inventory of workflows with their triggers and the fields they use makes that check quick. Reviewing the inventory on a regular schedule also helps you retire rules nobody needs.

A Hypothetical Example

A user reports that renewal reminder tasks stopped appearing. The admin opens an example account and finds no task history for the past few weeks. The rule is active, so she reads its condition and sees it looks for accounts whose type equals “Customer”. She then discovers that an earlier cleanup renamed that value to “Active Customer”. She updates the condition, tests with one account of each type, and runs a report to find accounts that should have received a reminder during the gap. Finally, she adds a note to the rule explaining which field values it depends on, so the next person who edits those values knows to check it.

Frequently Asked Questions

Why did a workflow work for months and then stop? Usually because something it depends on changed: a renamed value, a deleted field, a deactivated user or a new rule that interferes. Review recent configuration changes first.

How can I tell whether a workflow or a person made a change? Field history and activity logs normally show the user or process responsible. Details differ by platform, so consult the vendor’s current documentation.

Is it safe to disable a misbehaving workflow immediately? Often yes, if the damage is spreading, but consider what depends on it. Disabling may stop a needed process, so tell the affected team.

Should I rebuild the workflow from scratch? Rarely as a first move. Diagnose the cause first; a rebuild can reproduce the same flaw if you do not understand it.

How do I stop duplicate emails? Check for overlapping rules and for updates that re-trigger the rule. Adding a clear stop condition, such as a flag field set after the first run, usually resolves it.

Next Step

Take the last workflow complaint you received, run it through the four steps above using one real example record, and write down the cause and fix in the rule’s description for future reference.