Routing & Automation
Part of Support technology improvement
Removing conflicting support automation rules
Trace conflicting rules through a support case, assign each decision an owner and check the ticket path after a narrow change.
Remove or revise a conflicting rule only after identifying the case outcome it was meant to protect. Trace an affected case through the relevant rules, agree which rule owns each decision and check the resulting path after a narrow change. Disabling a rule by name alone could remove a needed notification or leave work unassigned.
Pros and cons of disabling a rule by name alone
- ProsQuick action to stop unintended behaviour.
- ConsMay remove needed notifications or leave work unassigned; can break intended process flow.
Trace the affected case
Start with a case that ended in the wrong state: its group changed twice, for example, or two rules assigned different priorities. Remove identifying details from the review record. Write down the expected group, owner, status and next action before examining the rule history.
Zendesk ticket Events show recorded updates and notifications made by people and business rules. Its Rules analysis identifies where properties such as groups, agents and tags are used across rules.
Events have a limit: a trigger action that makes no net change to ticket fields may not appear in the event log. Inspect the rule configuration as well as the case record.
Freshdesk's Show Activities view can identify an automation rule acting on a ticket. Its ticket-creation rules can run the first matching rule or all matching rules.
In first-match mode, a broad rule above a specific one may prevent the specific rule from acting; in all-match mode, overlapping rules may both act. These modes describe ticket-creation rules, not every Freshdesk automation.
Freshdesk automation rule execution modes
- First-match mode
- Executes only the first matching rule; broader rules may block specific ones.
- All-match mode
- Executes all matching rules; overlapping rules may both act, causing conflicts.
Key facts about Zendesk ticket event logging
- Event log limit
- Triggers that make no net change to ticket fields may not appear.
- Rule order matters
- Zendesk triggers run in listed order; earlier actions affect later trigger firing.
Decide which rule owns the outcome
List the rules that could affect the cases. For each, record its event, conditions, actions, owner and purpose. Mark rules that set the same field, move the same case or depend on a field another rule changes.
| Conflict found | Decision to make |
|---|---|
| Two rules choose different groups | Which rule owns the initial destination, and what handles the exception? |
| One rule reverses another's assignment | Which condition should be narrowed or removed? |
| A rule has no process owner | Is its purpose still needed, and who accepts its retirement? |
Describe the intended process in ordinary language before editing conditions or order. If process owners disagree about the destination, settle that decision first.
Make a narrow change and inspect the result
Capture the current configuration and assign someone to correct the change if it fails. Narrow, reorder or deactivate only the rules needed to express the agreed decision. Zendesk notes that triggers run in listed order and that actions from one trigger can affect how other triggers run and fire.
Use safe sample cases for a match, a near match, a missing field and a later update. Inspect the final group, individual owner, status, recorded events and customer-facing action.
Then review affected real cases during a limited release. A restored rule will not necessarily undo changes already made to tickets, so identify those cases for separate correction.
Tell affected agents the new decision and how to report an exception. Keep, revise or restore the rule based on whether cases reach an accountable next step.
