What a workflow is
A workflow is the path a piece of work takes from start to finish, and the rules about who does what along the way.
An order arrives. Somebody checks the credit position. Somebody approves the discount. The warehouse picks it. Accounts invoices it.
That path exists in every business. The question is whether it exists in the system or only in people’s heads.
When it lives in the system, the steps happen in order, the right person is asked, and there is a record. When it lives in people’s heads, it works until somebody is on leave.
Where Odoo already enforces one
Before building anything, know what is already there. A surprising amount is.
Document states. A quotation cannot be delivered until confirmed. An invoice cannot be paid until posted. These are workflows, and they are built in.
Approval thresholds. Purchase orders above a set value need a manager. Configured in Settings, not built.
Stage-based flows. CRM pipelines, project tasks, helpdesk tickets. You define the stages and work moves through them.
Follow-up levels. Overdue invoice reminders at intervals you set, escalating to a person.
Reordering rules. Stock below a minimum triggers a purchase or a manufacturing order.
Check these first. A large share of “we need a custom workflow” requests are settings somebody has not found.
FIGURE 1: WHAT ODOO ALREADY DOES BEFORE YOU BUILD ANYTHING
Document states
- Confirm, validate, post. The sequence is enforced already.
Approval thresholds
- Purchase orders above a value need a manager. A setting, not a build.
Stage pipelines
- CRM, projects, helpdesk. You define the stages.
Follow-ups and reordering
- Overdue reminders and stock replenishment, on rules you set.
The four levels of building one
Same ladder as any customisation, and picking the right rung is most of the decision.
Configuration. Settings, thresholds, stages, approval limits. No code, nothing to maintain, survives upgrades.
Automated actions. When something happens, do something. Configured in the interface.
Server actions. Reusable pieces of work, run from a button, a schedule, or another action.
Custom module. Real business logic, written in code, version controlled and testable.
Work down the list, not up. Most requests are satisfied at level one or two, and each level down costs more to build and more to maintain.
Approval workflows
The most common request, so worth its own section.
What standard Odoo gives you: a single value threshold on purchase orders. Above the number, a purchase manager approves.
What businesses usually want beyond that:
- Different approvers depending on the amount
- Different approvers by category or department
- Two approvals above a certain value
- Different rules per company in a group
- An approver who is not the line manager
None of these are in standard Odoo. They are a common and well-understood custom module, and they are usually worth building — approval rules that live only in people’s heads are the first thing to break under pressure.
Before commissioning one, write the rules down completely, including what happens when the approver is on leave. That last case is the one that gets forgotten and the one that causes the most trouble.
FIGURE 2: APPROVAL RULES THAT WORK AND ONES THAT DO NOT
Working
- Written down completely before building
- A defined route when the approver is away
- Enforced by the system, not by habit
- Recorded on the record
Not working
- Rules that live in people’s heads
- Nobody knows who approves when someone is on leave
- Worked around when there is a deadline
- Approved on a chat message nobody can find
Designing a workflow
Five questions before anything is configured.
What triggers it? A record being created, a field changing, a value threshold, a date passing.
What are the steps, in order? Write them out. If you cannot list them, the process is not settled and software will not settle it.
Who does each step? By role, not by person. “The purchase manager”, not “Priya”.
What happens at each decision point? Approved, rejected, or sent back — and what each means for the record.
What happens when somebody is unavailable? The case everyone forgets.
If you cannot answer all five, stop. Automating an unclear process makes the confusion move faster, and it becomes harder to see because it is now hidden inside software.
What automation should not do
Three limits worth holding.
It should not remove judgement. A rule can route a decision to the right person. It should not make the decision where consequences are significant.
It should not create silent failures. If a step fails, somebody must know. A workflow that quietly stops is worse than one that never existed, because people assume it is working.
It should not be a substitute for a decision. Sometimes a workflow request is really two departments failing to agree, and asking the system to keep both versions alive. That is not a technical problem.
Keeping it maintainable
Four practices.
Document every rule and why it exists. In two years nobody will remember why orders over a particular value need two approvals.
Name things descriptively. Not “Automation 4”. Something that says what it does.
Review annually. Business rules change. Some workflows enforce a process you stopped using.
Test at upgrades. Anything in a module needs checking against a new Odoo version.
FIGURE 3: THE ORDER TO BUILD IN
Check settings first
- More is configurable than people expect
Try automated actions
- When X happens, do Y
Use server actions
- Reusable work, run several ways
Build a module
- Real logic, tested and version controlled
What goes wrong
Automating a process nobody agreed on. The most common and the most expensive.
Too many rules. Thirty automations nobody can untangle, added by different people over two years.
No route when someone is away. Work stops, and people work around the system to get it moving.
Silent failures. A scheduled step stops running and nobody notices for weeks.
Rules enforced so tightly that work cannot proceed. People find ways around the system, and now you have neither control nor visibility.
That last one is worth watching for. A workflow that people route around is worse than none, because it gives the appearance of control without the substance.
Getting started
- Write down how the process actually works today, including exceptions
- Identify what already exists in Odoo settings
- Configure what you can without building
- Add automated actions for the simple rules
- Build a module only for genuine business logic
- Document every rule and who asked for it
- Review annually
Point 1 is the whole exercise. Companies that write the process down first end up building less and getting more.
The short version
A workflow is your process, enforced by the system rather than remembered by people.
Check settings first — more is configurable than most people realise. Then automated actions, then server actions, then a module.
Write the rules down completely before building anything, including what happens when the approver is on leave.
And if the process is unclear on paper, fix that first. Software will not settle a disagreement.
Approvals happening on chat messages nobody can find?
Get in touch. We will map how your process actually works, then build only what settings cannot already do.
