Short answer
Case management gives one business issue a durable record from trigger to outcome. A useful case shows the current owner, state, next action, due point, linked source record, required evidence, decisions and communications. It closes when the business outcome is confirmed—not merely when the last task is ticked off.
A case is not needed for every to-do. Use one when the work may cross people, systems or days; when evidence or approval matters; or when an exception needs a clear path to resolution.
Case, task and transaction: different jobs
| Item | What it answers | Example |
|---|---|---|
| Transaction or master record | What was ordered, billed, paid, owned or supplied? | The invoice and supplier record in the ERP. |
| Task or activity | What should one person do next? | Call the supplier by Thursday. |
| Operating case | How will this issue move through owners, evidence and decisions to a confirmed outcome? | Resolve a disputed delivery and reconcile the resulting invoice. |
The case should link to, not replace, the authoritative transaction. If an existing Odoo ticket or application record already carries the complete journey, improve that record rather than creating a duplicate case.
The minimum useful case record
- Identity: a stable case reference and links to the customer, asset, supplier, order or transaction it concerns.
- Trigger and outcome: why it opened and the condition that will prove it is finished.
- Current owner: one person or role accountable for the next move, with a backup or escalation path where needed.
- State and next action: a plain-language stage, a short verb-object action and an agreed due point.
- Evidence: source documents, photos, inspections, communications or approvals, each attached or reliably linked in context.
- Decision: who may approve, reject, return or escalate, and what facts the decision relied on.
- History: changes of state, ownership, evidence and decision that a reviewer can reconstruct.
Collect only fields that support a real decision or control. A long form with no clear use will create administration and poorer data.
A practical lifecycle
- Open: capture the trigger, source record and initial owner. Check whether an equivalent case already exists.
- Triage: classify urgency, risk and the required outcome. Route to the right owner rather than a generic inbox.
- Gather: request missing information, record who owes it and set a review date. Keep the case visible while waiting.
- Decide: apply the policy or approval authority to the evidence available at that point.
- Execute: make the authorised change in the system of record, or record why the request was rejected.
- Confirm: read back the source transaction, communicate the outcome and check that no required action remains.
- Close or reopen: close with a reason and proof; reopen under an explicit rule if new material facts appear.
Example: a service failure across three teams
A customer reports that a repaired asset has failed again. A service case links the customer and asset records. The service coordinator owns triage, requests a photo and assigns a technician. The technician records the finding and parts used. A manager decides whether the repair is covered under the applicable agreement. Finance or the ERP records any authorised charge or credit. The coordinator confirms the customer has the outcome and that the source records agree before closing the case.
The case would be weak if it merely said “technician attended”. The useful record explains the failure, evidence, decision, commercial consequence and customer communication. This is an illustrative journey; actual Intelliflow forms, permissions and integrations must be tested in the target deployment.
Make handoffs explicit
At each handoff, record the sending owner, receiving owner, acceptance point and what evidence must travel with the work. A case left in “waiting” without a blocker owner and review date is not controlled. Distinguish business aging—such as a legitimate wait for customer evidence—from a technical fault where a rule or notification failed. They need different recovery actions.
Evidence and communication without duplication
Keep the original evidence or a dependable link to its authoritative location. Label customer messages separately from internal notes. Record decision-time evidence so later additions do not rewrite what the approver saw. Apply role-based access: a status viewer may need to know that proof is complete without viewing a sensitive document.
Closure rules that prevent false completion
Before closing, ask:
- Was the required decision made by an authorised person?
- Is the required evidence present and readable?
- Did the downstream transaction or operational action actually happen?
- Was the customer or next responsible team informed where the process requires it?
- Are child actions, exceptions and follow-ups complete or deliberately transferred to a named owner?
Do not equate a green case status with financial posting, customer receipt or external message delivery. Each needs its own proof.
Measures worth showing a manager
For a defined period and case type, track open cases without a named owner; cases without a next action and due point; median and 90th-percentile time in each state; blocked items with an accountable blocker owner; cases closed with required evidence; and cases whose linked transaction outcome matches the closure reason. Segment by risk and location before comparing teams.
Measure the pilot against a baseline. A lower open-case count may mean faster completion, but it may also reflect fewer cases being captured. Review sample cases, not only dashboard totals.
When not to create a case
A single action completed reliably inside an existing record may need only an activity. A case that copies the entire customer or invoice record creates reconciliation and privacy risks. If the workflow is already visible in Odoo Helpdesk, Project or another application, first test whether configuration and reporting there solve the gap.
Frequently asked questions
Will case management add administration?
It can if every small task becomes a case or fields are collected without a purpose. Start with one exception type, a minimum record and clear automation rules. Compare time spent on follow-up and rework before claiming a saving.
Who owns a case when several teams work on it?
Keep one current accountable owner for the next move, while individual actions may be assigned to specialists. Make the handoff and acceptance visible.
What proves a case is closed?
The policy-defined outcome, required decision and evidence, any downstream record change, and necessary communication. A task marked done is only one piece of that proof.
Continue learning
What Is a Process Operating System? · Evidence and auditability · Discuss a case journey
Written for practical education by the Intelliflow Editorial Team. Examples are illustrative; deployment behaviour and integrations require environment-specific proof.