Automation rules: turning a repeatable event into useful follow-up

Automation is appropriate when the same clear event should consistently produce the same kind of follow-up. It can reduce missed handoffs, but it needs a precise business rule. An instruction such as “remind the right person when an important document changes” is too vague until the document, change, conditions and recipient are defined.

A useful rule has a trigger, conditions and an action. The trigger identifies when to evaluate the rule; conditions narrow the cases; the action describes the intended result.

DNA's rule builder

DNA's automation builder provides event-based triggers such as creation, update, field change and status change, as well as a time-elapsed configuration. It associates the trigger with an entity type. The reviewed action selector offers task creation and notification sending.

Task actions include a task title and configuration. Notification actions include a message and recipient configuration, with subject validation for email-related channels. These settings describe an intended automated action; saving the rule does not prove that an event has occurred or that the recipient received a message.

A useful business rule

A fictional organisation may want a follow-up task after a relevant document reaches an agreed status. Before configuring that rule, it should decide who owns the follow-up, what the task means and which exceptions should be excluded. The chosen event and fields must be supported for the relevant entity.

Avoid broad rules that create work nobody owns or notifications nobody can act on. A meaningful message explains the business event and the decision or response needed.

Verify execution

DNA's Automation Logs view requests execution records and provides filters by rule and execution status, with search against the rule and triggering entity. These records help distinguish a configured rule from an attempted execution.

An empty log view may reflect filters, missing events or a loading failure. A successful execution record should still be interpreted according to the action's result; it is not independent proof that a person read a notification or completed a generated task. Review rules through their real outcomes, especially when conditions or recipients change.