Odoo module
StateFlow
Every state change, under control. Without writing code.
Define which state changes are allowed on any Odoo model, what must hold before they happen and what happens afterwards. You configure it from the interface and it is enforced on the server: it makes no difference whether the change comes from a button, an import, the API or another module.
Price€240One-off payment · taxes not included
Available for Odoo 16, Community and Enterprise. Adaptation to new Odoo versions is included for 12 months from purchase.
Schematic illustration. Not a screenshot of the product.
- 4
- moments in every transition: before and after leaving and entering
- 6
- validation types that block the change
- 10
- automatic action types after the change
- 195
- automated tests passing before every release
In motion
This is what a flow looks like with StateFlow
The cards, the arrows, the rules panel and the simulator, just as they appear in Odoo: you draw a transition, open the rules of a state and check a change before making it.
The problem
In Odoo, the rules of a state are scattered across the code
Stopping an order from being confirmed without a delivery date, requiring a reason for a cancellation or notifying the owner when a task is approved usually ends up as development work: an overridden method, an automated action that does not know where the record comes from, or a button that checks what another entry path skips.
Every rule is a development
Required fields per state, permissions to move forward or notifications on a stage change are coded model by model. Changing a business rule means deploying code.
The button checks, the import does not
If the check lives in the button, an import, an API call or a drag in the kanban view goes around it. The record ends up in a state it should never have reached.
Nobody knows how long each stage takes
The chatter says something changed, but not how long a record spent in each state, who moved it or why. Measuring bottlenecks means exporting and cross-referencing data.
StateFlow brings it all together: one flow per model, configured from the interface, enforced at a single point on the server and logged transition by transition.
Four moments
A transition has four moments, and you can act on each one
Leaving a state has its own effects too, not just entering the next one. Each rule hooks into one of the four moments and is limited to a specific transition (from Quotation to Confirmed) or to any entry into or exit from a state.
- 01
Before leaving
Checks that the current state is finished: for example, that no activities are left pending.
Can block
- 02
Before entering
Requires what the target state needs: filled-in fields, a condition or a permission.
Can block
- 03
After leaving
Tidies up what the previous state leaves behind: cancels or closes the activities the flow opened in it.
Does not block
- 04
After entering
Gets the new state going: schedules activities, sends emails, writes fields or notifies another system.
Does not block
And a fifth one, the overdue deadline: if a record spends more hours than planned in a state, its actions run once per stay.
What you can configure
Validations that block and actions that work for you
Validations come before the change and, if one fails, the whole transition is rolled back. Actions come after and never move the state of the record in transition: no loops and no records left halfway.
Can block Validations
Required fields
Lists all the empty fields at once, not one by one.
Domain condition
The record must match an Odoo domain; you write the message.
Group
Only members of some groups can make the change.
No open activities
The state cannot be left with pending activities of the types you choose.
Child records
All lines or subtasks must meet a condition; it says how many fail.
Python code
For special cases, an expression evaluated safely. Only system administrators can configure it.
Does not block Actions
- Schedule an activity
- Cancel activities
- Mark activities as done
- Post in the chatter
- Send an email from a template
- Add or remove followers
- Write fields
- Run a server action
- Call a webhook
- Request another transition
Recipients that follow the team
Activities, emails and followers accept users, groups, a field path (the order's salesperson, the project manager) or the rows of a filtered relation. The configuration keeps working when people change. Texts can include the reason, the source state and the target state.
The flow's own activities
Every activity a rule creates remembers where it came from. When the state is left, "cancel this state's activities" closes only those, never the ones someone created by hand.
Transition control
Only allowed changes happen, by the right people, with their reason
You draw the allowed transitions and the engine rejects the rest. Each one can require groups and a reason, and when something fails the user gets a single message with everything that is missing.
Strict mode
With transitions defined, any change not listed is rejected. With none, every change is allowed and only the rules apply: you can adopt the module step by step.
Groups per transition
Approving can be reserved for Management while Sales moves everything else. The server enforces it even when the change comes through another path.
Mandatory reason
Rejecting, cancelling or reopening can ask for a reason. A dialog opens, the change is replayed with the reason, and the reason is kept in the history.
One message with everything
Every missing field, for every record in the batch, in a single notice with each record's reference. No fixing one error at a time.
No loops
Only the engine moves states
An automation that changes the state of the record that triggered it is the classic recipe for an endless loop or a dead record. StateFlow prevents it in two layers and offers a safe way to chain changes.
When the configuration is saved
A rule that would write the state field is rejected before it is saved, with a message that explains why.
At run time
While its rules run, the record is marked as "in transition". If a server action tries to change its state, the operation is rolled back with a clear error.
Controlled chaining
For "when all subtasks are done, close the parent task" there is the Request transition action: it queues the request and the engine runs it at the end, with all its validations and its own entry in the history.
Cycles and depth
Chained changes between different records are watched: if the same record reappears in the chain or the maximum depth (3 by default) is exceeded, the operation is aborted.
Flow map
You see the whole flow, and edit it on the map itself
One card per state and one arrow per transition, with the real data of your database: how many records are in each state right now and how long they spend there on average.
- Drag the cards into place, or let the automatic layout arrange them.
- Create a transition by dragging from one card to another; delete it after confirming.
- Click a state or an arrow and, in the side panel, see and edit its rules grouped by moment.
- Arrows show whether the transition asks for a reason, has a button or carries a deadline; background rules stand out at a glance.
- Each card's count opens the list of the records currently in that state.
Simulator
Ask what would happen before moving anything
You pick a real record and a target state, and the simulator tells you whether the change would go through or be rejected, which validation fails and which actions would run afterwards. It writes nothing and runs no action. Try it here with a sample order.
In the product, the map also highlights the current and target states, in green or red depending on the result.
Order S00128 · current state: Quotation
Move to
✕ Would be rejected
Transition
- Transition allowed in this flow
- You have the Sales / Manager group
Validations
- Customer filled in
- Fill in Delivery date before confirming
- Every line has a product
Would run afterwards
- Nothing
A record's journey
The history the chatter does not give you: who, when, why and for how long
Every transition leaves a line with source, target, user, date, reason, result and the hours the record spent in the previous state. The journey draws it step by step and hangs underneath the records that moved because of each change.
- Time in each state, including the current one, to find bottlenecks without exporting anything.
- Parent-child chain: you see which change caused another, even on a different model.
- Raw log filterable by flow, model, user or result, for audits.
- It respects permissions: branches to other records only appear if you can read them.
Reliable automation
You decide what happens when an action fails
Not every action weighs the same. Those that keep the data consistent roll the change back if they fail; a non-critical notice should not prevent it; a call to another system deserves retries.
| If the action fails | What happens | When to use it |
|---|---|---|
| Roll back (default) | The whole transition is reverted. | Actions the data depends on. |
| Log and continue | The change stays; the error is kept in the history and in the chatter. | Non-critical notifications. |
| In the background | It runs after the change is committed, with retries after 5, 10, 20 and 40 minutes. | Bulk emails, webhooks and external calls. |
Deadlines per state
Set how many hours a record may spend in a state. When the deadline passes, its actions run once per stay: a reminder, an escalation or a requested change.
Protected webhooks
Send the model, the record, the states, the user and the fields you choose to another system. Internal or private addresses are rejected and redirects are not followed.
Export and import flows
Move a flow from testing to production, or from one customer to another, in a file. Whatever cannot be resolved at the destination is reported and skipped, and the flow arrives archived so you can review it before activating it.
Visible, retryable jobs
Every background action has its own record with attempts, last error and a button to retry it. Nothing fails silently.
Generated buttons
The form's buttons come from the transitions themselves
Give a transition a button label and it appears on the form when the record is in its source state. The first one is highlighted; users without the required group do not see it. When clicked, the change goes through the same engine as any other path.
Comparison
What changes compared with solving it with what Odoo ships
The comparison is with the tools Odoo includes out of the box (stages, automated actions and custom development), not with specific third-party modules.
| Need | Standard Odoo | StateFlow |
|---|---|---|
| Limit which states can be reached from each one | Coding the method or button of each transition. | Transitions drawn on the map; the rest is rejected on the server. |
| Required fields depending on the target state | Python constraints or view attributes (screen only). | A declarative validation that lists everything missing, on any entry path. |
| Ask for a reason when rejecting or cancelling | A wizard developed for each case. | A checkbox on the transition; the reason is kept in the history. |
| Actions on a state change | Automated actions with no notion of source and target and no loop protection. | Four moments per transition, an error policy and loop protection. |
| Time each record spends in each state | Rebuilt from the chatter or from custom reports. | Stored on every transition, with averages per state on the map. |
| Know why a record cannot be moved | Try it and read the error, or review the code. | The simulator explains it without touching the record. |
| Get notified when a record gets stuck | A scheduled action written by hand. | A deadline in hours on the state itself, run once per stay. |
A rule that only lives in a button is not a rule
If the check is in the interface, an import, the API or a drag in the kanban view goes around it. StateFlow hooks into the model's write, the one point every path goes through.
Safe by default
Native Odoo mechanisms, no external services
No flows, no change
With the module installed and no flows defined, Odoo behaves exactly as before. A model without a flow leaves the engine immediately.
A single entry point
Buttons, imports, the API, drags and other modules go through the same engine. So do computed stored states, such as a task's stage.
Never left halfway
Validations and critical actions run in the same transaction as the change. If one fails, everything is rolled back, even if the caller catches the error.
Sensitive options for administrators only
Python code, expressions, webhooks and running as superuser can only be configured by a system administrator, also when a flow is imported.
No key, no external service
No activation key and no connection to any service. Your data does not leave your Odoo, except through the webhooks you configure.
Designed not to slow Odoo down
The configuration is cached and the cache is cleared when a flow changes. A batch of records runs each rule once per group, not once per record. We do not publish benchmarks.
Who it is for
For whoever answers for processes being followed
Operations managers
They see where records pile up and how long each stage takes, and adjust the rules without waiting for a development.
Integrators and consultants
They deliver closed, reviewable processes, with flows exported from testing to production and reused across customers.
Companies with audits or certifications
They need to prove who approved what, when and with what reason, and that no record skipped a step.
Common use cases
- An order cannot be confirmed without a customer, a delivery date and payment terms.
- Only Management approves purchases above an amount.
- Cancelling an opportunity or an invoice always asks for a reason.
- A task cannot be closed with open subtasks, and the project moves on when they are all closed.
- Approving a ticket creates an activity for its owner and notifies the customer.
- A quotation with no answer in 72 hours triggers a reminder to the salesperson.
What the purchase includes
Terms of purchase
What you get, for how long and under what terms.
- Module
- The complete StateFlow: transition engine, validations and actions, flow map, simulator, journey and history, generated buttons, deadlines, background actions and flow export and import.
- Odoo versions
- Odoo 16. If your company uses another version, say so in the request and we will tell you when it is available before charging anything.
- Editions and hosting
- Developed and tested on Odoo Community. It only depends on the base and mail modules, so it installs the same way on Enterprise, on Odoo.sh and on self-hosted servers. It cannot be installed on Odoo Online (standard SaaS), because Odoo does not allow third-party modules on that service.
- Licence
- OPL-1 (Odoo Proprietary License v1.0): the code is readable and you can adapt it for your own use, but not redistribute it.
- Licence scope
- One licence per company. It covers its production database and all its testing, staging and development databases, with no limit on users or flows. An integrator needs one licence per end customer.
- Updates
- Bug fixes with no time limit for the versions purchased. Improvements, new features and adaptation to new Odoo versions, included for 12 months from purchase.
- Support
- By email, in Spanish and English, for 12 months from purchase. First reply within 2 business days at most. It includes help with the installation and with setting up your first flow. It does not include custom development: see our custom development service.
- Refund
- 30 days, no conditions: if the module does not fit, the full amount is refunded. If a conflict with another module appears within those 30 days, we fix it or refund you.
- How it is delivered
- After your request, you receive the invoice and payment instructions by email. Once the payment is confirmed, you receive the module download link and the installation guide within one business day at most.
- How it is charged
- €240, one-off payment, no subscription or fees. Taxes not included: they are applied according to your country and tax status and itemised on the invoice.
- Brand behind it
- uKodeIT signs and sells the module.
Frequently asked questions
Common questions before installing it
What happens if I install the module and create no flow?
Nothing. Odoo behaves exactly the same. A model without a flow does not go through the engine, and a flow with no transitions defined allows every change and only applies its rules.
Which models does it work on?
Any model with a selection state field (such as state) or a relation to stages (such as stage_id). It has been tested with sales orders and project tasks, as well as its own test model. You can have several flows on the same model, separated by a domain or by company.
Can it be bypassed with an import, the API or a drag in the kanban view?
No. The engine hooks into the model's create and write, which all those paths go through. The only thing left out is direct SQL writes, which do not go through the Odoo ORM.
Can an action cause a loop?
An action cannot change the state of the record in transition: it is rejected when the rule is saved and, if a server action tries it at run time, the operation is rolled back. Chained changes on other records have cycle detection and a configurable maximum depth.
Who can configure the flows?
Users of the StateFlow / Administrator group, which administrators receive on installation. The map and the simulator are reserved for that group. Python code, expressions, webhooks and running as superuser also require being a system administrator.
Does it work on Community, Enterprise, Odoo.sh and Odoo Online?
Yes on the first three: it is developed and tested on Odoo Community and only depends on the base and mail modules. It cannot be installed on Odoo Online (standard SaaS), because Odoo does not allow third-party modules on that service.
How does it affect performance?
If the model has no flow or the write does not touch the state field, it exits immediately. The configuration is read from a cache and batches group records to run each rule once per group. Heavy actions can run in the background. There are no published benchmarks.
What happens if a background action fails?
The state change has already happened and is not undone. The action is retried after 5, 10, 20 and 40 minutes, up to five attempts, and its record keeps every error and a button to retry it by hand.
Can it conflict with other modules?
The module hooks generically into the create and write of models that have a flow, and we cannot guarantee compatibility with every third-party module. Our commitment is this: if a conflict appears within the first 30 days, we fix it or refund you. Even so, it is best to try it first on a copy of your database.
Does it need an activation key or a connection to an external service?
No. The module works entirely inside your Odoo. Information only goes out if you configure a webhook.
Purchase
StateFlow for Odoo
€240
Taxes not included: they are applied according to your country and tax status and itemised on the invoice.
One-off payment. One licence per company, with its production and testing databases. Full refund within 30 days.
Leave us your details and you will receive the invoice and payment instructions by email. Once the payment is confirmed, we send you the download link and the installation guide within one business day at most.
uKodeIT is an independent Odoo integrator and is not an Odoo S.A. partner. Odoo is a trademark of Odoo S.A.
Processes that are followed, not remembered
Draw the flow, check it with the simulator and let the server enforce every transition, wherever it comes from.
€240