Short answer
A rules engine reduces manual follow-up when a repeatable policy can be expressed as a clear trigger, condition and action. It can assign work, request missing evidence, set a due point, remind an owner or escalate a genuine exception. It should not automate a decision that the business has not agreed or hide the reason a rule fired.
Start with a small number of high-frequency follow-ups. Measure whether fewer items are left unowned or overdue, not just whether more notifications were sent.
The anatomy of a useful rule
| Part | Question | Example |
|---|---|---|
| Trigger | What event starts evaluation? | A new inspection finding is saved. |
| Condition | Which records qualify? | Outcome is adverse and a photo is required but missing. |
| Action | What should happen? | Keep the case open and assign an evidence request. |
| Owner and due point | Who must act, and by when? | Inspection owner, before the agreed review point. |
| Exception | What if the normal path cannot complete? | Escalate to a named supervisor with the missing-proof reason. |
| Evidence | What shows the rule worked? | Rule version, input state, assignment and later resolution in the case history. |
Write the rule in ordinary business language before configuring it. If the policy cannot be explained to an owner, automation will make the confusion faster rather than solve it.
Four rules worth considering first
- Route: when a request arrives, assign it by region, product or case type. Provide a fallback owner for unknown values.
- Require evidence: prevent a decision or closure until the policy-defined document or inspection result is present and readable.
- Remind: prompt the current owner before a due point, once, with the missing action and source record attached.
- Escalate: when the due point passes and the case remains unresolved, assign a named escalation owner and retain the reason.
These rules address different failures. A reminder does not replace escalation, and an escalation should not fire just because a case is old when the business is legitimately waiting for an external party.
Example: a supplier document exception
A purchase request requires a supplier compliance document. The request arrives without it. A rule marks the evidence requirement as open, assigns the requester to obtain the document and sets a review date. The approver cannot make the policy-controlled decision from an empty file link. If the due point passes, the supervisor sees a specific exception: document missing, current owner and elapsed time.
When the document arrives, an authorised person checks it, records the result and resumes the request. The resulting purchase or rejection must be confirmed in the ERP. The rule can coordinate the chase; it cannot prove that a supplier is compliant or that the transaction was completed.
Test the rule before it sends noise
- Happy path: qualifying record receives exactly the intended action.
- Non-match: a similar record outside the condition receives no action.
- Missing data: blank region, owner or due date goes to a controlled fallback, not a dead queue.
- Duplicate event: resaving the same record does not create repeated reminders or cases.
- Loop: a rule's own update does not trigger it again indefinitely.
- Changed facts: a material change re-evaluates the rule under policy without erasing the previous decision.
- Access: the assignee can see what they need, while sensitive evidence remains limited to authorised roles.
- Failure and recovery: a failed notification or integration leaves a visible error and a named recovery owner.
Odoo 18's automation documentation warns that an automation can run multiple times when its update trigger is not scoped carefully. The same design caution applies to any rules platform: test repeat events and idempotency before rollout.
Give each rule an owner and a version
Record the policy owner, effective date, reason, inputs, action, exception route and expected evidence. Keep a change history. Before replacing a rule, review open cases that started under the previous version; their decisions should remain explainable. An emergency override needs authority and a reason, not a silent bypass.
What the dashboard should show
Managers need more than a count of rules fired. Show unowned work, reminders that did not lead to action, escalations by reason, repeated missing evidence, time spent blocked, and cases that reached the underlying business outcome. Review false positives as well: a rule that catches too much can slow good work.
Compare one process before and after implementation. Keep volume and case mix visible. Fewer manual chases are useful, but a financial saving requires separate time, rework and cost evidence.
When not to automate
Do not automate an unclear policy, a low-volume judgement call or a decision whose evidence cannot be checked. Fix the policy and ownership first. A simple activity in the existing application may be better than a new cross-system rule. Add a case or integration only where the process genuinely spans records or teams.
Frequently asked questions
Will rules make the process rigid?
They can if exceptions are not designed. Define an authorised return, override and escalation path, and keep the reasons visible.
Is an automated reminder proof that work was done?
No. It proves that a message or activity was generated only if that action is recorded. Completion needs the required decision, evidence and downstream record state.
Where should a team start?
Choose one repeated follow-up with a clear owner and policy, capture a baseline, configure one rule, and test both qualifying and non-qualifying records before expanding.
Continue learning
Odoo workflow automation: native-first guide · Evidence and auditability · Discuss a repeatable follow-up
Source and scope
Odoo 18 automation rules documentation describes triggers, conditions and actions. This guide is general operating design, not a statement that any specific Intelliflow rule is deployed or that a customer result has been achieved.