Triggers, automations and SLAs that behave the same after the move

Business rules are where helpdesk migrations quietly go wrong. A trigger that fires in a slightly different order, an automation that runs twice, an SLA clock that pauses at a different moment: none of it shows up in a demo, all of it shows up in the first week. This is how ChaosDesk avoids that.

The same model, not a translation layer

ChaosDesk’s rules engine follows the same model as the rules you already have:

• Triggers run on every ticket update, by category position and then trigger position, with uncategorised triggers first.
• Automations run on time, need a condition that becomes false after they act (so they fire once per ticket until it changes), work through tickets in batches, and stop acting on a ticket once automations have updated it 100 times, which is our guard against a pair of rules looping.
• Conditions cover every ticket property and custom field, including “contains at least one of the words” with quoted phrases and whole-word matching.
• Actions include notifications, webhooks, side conversations and text messages. An action that would break a ticket rule (for example solving an unassigned ticket) is skipped and recorded, while the other actions still run.

Measured against a corpus

We keep a corpus of Zendesk rules and macros and run it against the engine on every change. To be clear about what it is: it is synthetic, not borrowed from anyone’s account. It is a fictional online shop whose rules were written to cover every Zendesk condition, operator and action the importer maps, plus the edge cases real accounts turn out to have — channels ChaosDesk does not have, drop-down values that are not options, triggers that solve unassigned tickets, deleted groups, retired targets, multi-word tag lists, non-ASCII words, mixed-case addresses, stray whitespace.

A coverage report records which conditions and actions are supported and which gaps remain, and behaviour tests check that rules produce the same result. The report is pinned to a stored baseline in both directions: a new gap fails the build, and so does a gap we closed, until someone updates the baseline deliberately. That is duller than a number that only ever goes up, and it is why the number stays true.

SLAs with the standard metrics

SLA policies cover the five standard metrics (first reply time, next reply time, periodic update, requester wait time and agent work time), with business schedules and holidays. Pre-breach alerts are automations on an SLA condition that reads “this target has used at least N % of its time”, where N is any 5 % step from 5 to 95, so the familiar 70 / 80 / 85 / 90 % ladder comes over from Zendesk with the rest of your automations rather than being hard-coded here.

When a rule cannot be mapped

Some rules use a feature ChaosDesk does not have yet. The importer imports them inactive and lists them in the unmapped-rule report, with the condition or action that blocked them. You decide: rewrite, replace with a native feature, or drop.

Check it on your own rules

The parallel run exists for this: your leads see their own rules acting on real tickets before anyone answers a customer in ChaosDesk.

More about automation in ChaosDesk.

Zendesk is a trademark of Zendesk, Inc. ChaosDesk is not affiliated with Zendesk.