Automation Conflicts and Debugging
Find out why a rule did not run, ran more than once, or produced an unexpected result, then adjust your automation safely.
Automations are powerful because they react to real task changes. That also means a rule can look correct but still miss the event you expected, overlap with another rule, or fire in a chain after a different rule changes the same task.
Use this guide when you need to slow down, inspect the rule, and make one careful change at a time.
Automation tests can change real tasks
When you test a rule, PrimeTask runs it on the task you choose. Use a throwaway task when you are checking a risky rule, and back up first if you are testing broad changes.
What you can do
Check why a rule did not run
by reviewing the master switch, rule toggle, trigger, and conditions
Find overlapping rules
when multiple automations react to the same task change
Reduce accidental chains
by checking action order and follow-up triggers
Test safely
with a task you are comfortable changing
Use manual runs deliberately
when you want a rule to run on demand
How to debug an automation
- Open Automations: Go to Settings → Automations.
- Open the rule: Select the built-in or custom rule you want to check.
- Check the Space: Confirm you are working in the Space where the rule should run.
- Review the trigger: Confirm the event you expected is the event the rule listens for.
- Review conditions: Confirm the task you tested actually matches every required condition.
- Test carefully: Use the rule's test action with a task you are willing to change.
- Run manually: If the rule uses a manual trigger, run it from the command palette or its assigned shortcut.
Things worth knowing
Start with the master switch
If nothing runs, first check that automations are enabled for the current Space. Then check that the individual rule is enabled. The master switch allows automations to run; each rule still has its own on/off state.
Conditions are the most common reason a rule does not run
A trigger can fire correctly while conditions prevent the action from running. If a rule should affect high-priority tasks with a specific tag, the task must match those requirements at the moment the trigger happens.
When debugging, temporarily simplify the rule. Remove one condition at a time, test again, then add conditions back once you know which part is blocking the run.
Multiple rules can react to the same change
Two rules can listen for the same task event. For example, one rule might start a timer when a task becomes active, while another rule shows a focus prompt for active high-priority tasks.
That can be useful, but it can also feel like one rule is doing too much. If a task change causes several results, review every enabled rule that listens to the same trigger.
Rule chains are possible
An action can create another task change. That new change can then trigger another rule. This is sometimes intentional, but it is also a common source of surprises.
If a rule sets a task's status, look for other rules that react to status changes. If a rule changes priority or tags, look for rules that react to those fields.
Debug one rule at a time
Disable nearby rules temporarily, test the rule you are checking, then turn the other rules back on one by one.
Action order matters inside custom rules
Actions run in the order you place them. If a notification should describe the final state of a task, put the task-changing actions before the notification. If a timer should start only after a status change, put the status action first.
Manual runs are different from event-driven runs
A manual automation runs because you asked it to run, not because a task event happened. Manual runs are useful for repeated workflows, but they can feel confusing if you expect the rule to wait for its normal trigger.
Built-in automations are not edited directly
Built-in automations can be enabled or disabled. If you need a different version of a built-in behavior, create a custom automation with the trigger, conditions, and actions you want.
Broad rules need careful testing
Rules with few or no conditions can affect many tasks over time. Add conditions when you only want the rule to affect a specific workflow, project, priority, tag, or status.
Common questions
"Why didn't my automation run?"
Check the current Space, the master automation switch, the individual rule toggle, the trigger, and the conditions. If all of those look right, test the rule on a task that definitely matches the conditions.
"Why did the rule run twice?"
Look for another enabled rule with the same trigger, or a rule chain where the first rule changes the task and the second rule reacts to that change.
"Why did a built-in automation conflict with my custom rule?"
Both can run if they react to the same task change. Turn off the built-in if your custom rule replaces it, or add conditions to your custom rule so the two behaviors do not overlap.
"Can I test without changing anything?"
The test action runs the rule on the task you choose, so choose a safe test task. For risky rules, create a temporary task specifically for testing and back up before running broad actions.
"Why did my manual automation ignore conditions?"
Manual runs are designed for on-demand workflows. Review the rule setup and test it with the task you intend to use. If you need strict matching, keep the conditions narrow and use a test task that reflects the real scenario.
"How do I know which rule changed a task?"
Start with the rules that match the timing and the task change you noticed. Review enabled rules with the same trigger, then check whether any rule could have started a chain by changing status, priority, tags, or timer state.
Where to go next
| If you want to… | Read this |
|---|---|
| Understand the automation system | Automations Overview |
| Review ready-made rules | Built-in Automations |
| Build a custom rule | Building Custom Rules |
| Check every trigger and action | Triggers and Actions Reference |
| Test or run rules manually | Testing and Running Rules |
| Back up before broad tests | Data Management |