Workflow automation: when a rule should NOT run

Most writing about automation explains what a rule can trigger. The harder question is the opposite one: when it had better do nothing. A rule that fires too often writes to customers who are expecting nothing, and two weeks later somebody switches it off. This is the structure that prevents that, and how you tell afterwards whether a rule is working or only looks like it.

A rule has four parts

The name. The part people underrate most. Six months from now it sits in a list with twenty others, and whoever reads it has to know what the rule does without thinking. “Notification 3” does not say.

The event. A rule does not wait for a time of day; it waits for something to happen in the business: a record is created, updated or deleted. Along with the event goes where: “a ticket is opened” is a different thing from “a quote changes”.

The conditions. The core, and the part most likely to be skipped. With no condition the rule runs on every event. With “priority equals high” it runs on the tickets that matter. The difference between a useful automation and one that gets turned off is almost always here.

The actions. What happens next: an email, a notice to the team, a WhatsApp message, a task, an updated field, a line in the history. Several in a row are allowed.

Before switching it on: the dry run

Before a rule goes live it deserves one dry run. The dry run evaluates the conditions and reports whether they would have been met and how many actions would have fired — without anyone receiving anything. It is the button that takes the fear out of switching on, and the only serious way to test a rule that emails real customers.

Why “skipped” is not a failure

After a few days the interesting question is not whether the rule is active, but what it actually did. That needs a log, and the log has to keep three outcomes apart:

• Succeeded — the work is done: the email went out, the notice arrived.
• Skipped — the event was there, but the condition was not true, or the record simply lacked the detail (a ticket taken over the phone, with no customer email address). The rule was not meant to run.
• Error — something went wrong, and the reason is stated: no recipient set, wrong credentials, a field an automation is not allowed to change.

Plenty of systems only know “ran” and “failed”. The result is that the log of a perfectly healthy rule fills up with red lines because the condition was not met on twenty tickets — and the one real error in the middle stops being visible to anyone. When you evaluate software, ask exactly this: is an unmet condition shown as a decision or as a fault?

What an automation should not touch

A rule that may overwrite any field is a risk, not a tool. What works is a fixed list of writable fields: status, owner, priority, a note. Totals, stock levels, accounting values and keys are not on it — those are changed by a person, or by an operation with a document behind it.

Just as important: a rule that writes must not be able to trigger itself. Without a brake, an automation that updates a field calls itself in an endless loop.

How Blina Desk does it

In Blina Desk the four steps are filled in on a single screen, in that order, with the dry run at the end. The actions are a closed list rather than open access to the database, and the updatable fields are settled in advance.

The log keeps succeeded, skipped and error apart, with the reason spelled out — so you can see at a glance whether a rule is not working or simply did not have to. And because automations belong to the company rather than to one person, management decides which rules are active and who may adjust them.

In the end the test for any automation software is the same: not how many templates it ships with, but whether two months from now you can still work out why a rule did not run on a Tuesday morning.