A single Odoo approval chain can depend on more than the visible approval steps. It may rely on user groups, company rules, approval thresholds, custom fields, automated actions, server actions, email templates, activities, inherited views, and integrations. Odoo approval chain dependency mapping before migration identifies those relationships before records and configurations move to a new environment. The result is a migration plan that preserves who approves what, under which conditions, and in what order, instead of treating approvals as isolated settings.
The most important detail to capture is the trigger-to-decision path. A purchase order approval might begin with an amount threshold, check the operating company, assign an approval group, create an activity, send an email, and block confirmation until a specific user completes the step. If one field, group, rule, or automation is missing in the target environment, the approval may route incorrectly or stop working altogether.
Why Approval Chains Need Dependency Mapping Before Migration
Approval workflows are business controls, not just interface features. They determine whether a quotation can be sent, a purchase order can be confirmed, an expense can be reimbursed, or a payment-related transaction can move forward. Migration planning must therefore examine the logic behind each approval chain, not only the records that appear in an approval screen.
Odoo approval dependencies generally fall into four connected layers:
Business conditions, such as order value, discount percentage, department, project, company, product category, or expense type.
Odoo configuration, including approval rules, stages, required fields, user groups, access rights, record rules, and company settings.
Automation, such as automated actions, server actions, scheduled activities, email templates, and notifications.
Technical extensions, including custom modules, inherited views, custom fields, external integrations, and code that changes the standard workflow.
The visible approval step is only one part of this chain. A migration that transfers the approval record but omits the group assigned to approve it does not preserve the control. A migration that transfers the group but changes a company-specific rule can create a different control.
Our Odoo migration services approach treats workflow verification as part of migration readiness. That means checking whether connected business processes still work with the migrated data, not merely confirming that records imported successfully.
What Should an Odoo Approval Dependency Map Include?
An approval dependency map should show each approval decision, its trigger, the people or groups involved, the records it affects, and every configuration or customization required for it to work. The map should be detailed enough for a functional consultant, technical consultant, tester, and business owner to understand the same process.
At minimum, document these fields for every approval chain:
| Mapping area | What to capture | Why it matters before migration |
|---|---|---|
| Business object | Purchase order, sales order, expense, invoice, project, request, or custom model | Identifies the records and modules that must move together |
| Trigger condition | Amount, company, department, discount, category, state, or custom field | Confirms which fields and values drive approval routing |
| Approval sequence | First approver, second approver, escalation, rejection, and resubmission | Shows the order and dependencies between decisions |
| Approver source | Individual user, user group, manager, department head, or dynamic rule | Reveals identity, group, and hierarchy dependencies |
| Access control | Access rights, record rules, multi-company restrictions, and permissions | Prevents an approver from seeing or acting on the request |
| Automation | Automated actions, server actions, activities, email templates, and notifications | Identifies behavior that might not be visible in the approval form |
| Customization | Custom fields, inherited views, custom modules, and code overrides | Determines what requires technical review or redevelopment |
| Integration | Connected systems, API calls, imports, exports, and synchronization rules | Exposes dependencies outside Odoo |
| Evidence | Configuration export, screenshots, test records, logs, and business confirmation | Creates a baseline for comparison after migration |
Use stable identifiers wherever possible. Odoo external IDs, technical field names, XML IDs, model names, and module names are more useful for migration analysis than labels alone because labels can be translated or changed between environments.
A business label such as “Manager Approval” does not explain whether the rule points to a specific user, a group, a department manager, or a custom method. The technical reference and the business explanation belong together.
How Do You Trace an Odoo Approval Chain?
Trace an Odoo approval chain from the event that starts it through the final action that releases the transaction. Do not begin with a list of approvers and work backward. Begin with a realistic transaction and observe what changes, who is notified, which state is updated, and what prevents the next step from occurring.
A useful trace follows this sequence:
Create the initiating record. Use a representative quotation, purchase order, expense, or other document with realistic values.
Change the triggering field. Test the amount, company, department, category, discount, or other condition that should activate the approval.
Record the first system response. Note the state change, approval request, activity, notification, or warning.
Identify the approver source. Confirm whether Odoo determines the approver from a user, group, manager relationship, department, or custom logic.
Test approval and rejection separately. These paths frequently trigger different activities, messages, state transitions, or downstream actions.
Test edits after approval. Determine whether changing a material field resets approval, creates a new request, or leaves the original approval intact.
Trace the release action. Confirm what becomes possible after the final approval, such as confirmation, posting, sending, or creation of another document.
This approach reveals hidden dependencies. For example, an approval might appear to depend only on order value, while the actual route also depends on the company on the order and the department assigned to the employee. A rejection might reset the document to draft, but a custom automated action could also create a new activity or notify a different group.
For each trace, capture the record ID, user, company, values that triggered the rule, timestamps, approval state, and resulting activities. These details make post-migration comparison much more reliable than screenshots alone.
Which Odoo Objects Commonly Affect Approval Chains?
Several Odoo objects and configuration layers commonly control approval behavior. The exact implementation depends on the Odoo version, installed applications, configuration choices, and custom development, so the dependency map should distinguish standard behavior from extensions.
Users and groups determine who can see, approve, reject, edit, or bypass a transaction. A user can belong to multiple groups, and group inheritance can affect permissions in ways that are not obvious from the approval form. Capture both the assigned group and the effective permissions relevant to the workflow.
Access rights and record rules determine whether the selected approver can reach the record and perform the required action. An approver may receive an activity but fail to approve because a record rule limits visibility by company, department, owner, or operating unit. The migration plan must test access with real user roles, not only with an administrator account.
Fields and selection values provide the conditions used by the chain. Custom approval fields, monetary fields, department fields, state values, and Boolean flags require careful mapping. A field that changes from a custom selection to a standard selection, or that uses different technical values in the target environment, can break a condition while leaving the form looking correct.
Automated actions and server actions may update fields, create activities, send notifications, or call custom code when a record changes. These actions can be triggered by creation, modification, a condition, or a timed rule. Include the trigger model, trigger event, domain, action type, and any referenced fields.
Views and buttons control what users can see and click. An inherited view may hide an approval button, add a status indicator, make a field required, or alter the conditions under which an action is available. A successful data import does not prove that the target user interface preserves these controls.
Email templates and activities support the human side of the process. Record the template, recipients, language behavior, notification method, responsible user, due-date logic, and links back to the source record. A workflow can technically complete while users miss approvals because its notifications point to the wrong template or recipient.
Custom modules and integrations may override standard methods or initiate approval requests from another system. Review module dependencies, installation status, model extensions, scheduled jobs, API credentials, and inbound or outbound event behavior before deciding what to migrate.
Our Odoo consulting services work is relevant when the dependency map crosses functional and technical boundaries. The goal is to separate standard Odoo configuration from custom behavior before the migration team commits to a target design.
How Should You Classify Approval Dependencies?
Classify each dependency by whether it is required for routing, required for permission, required for communication, required for auditability, or required for downstream processing. This makes risk easier to assess than labeling every object simply as “custom.”
A practical classification looks like this:
Routing dependency: A field, threshold, company, department, or hierarchy determines who receives the approval.
Permission dependency: A group, access right, record rule, or model permission allows the approver to act.
State dependency: A status value, button condition, or transition controls whether the next step is available.
Communication dependency: An email template, activity type, notification recipient, or scheduled action tells people what to do.
Audit dependency: Approval history, chatter messages, timestamps, user identities, and rejection reasons show what happened.
Downstream dependency: Confirmation, procurement, invoicing, fulfillment, posting, or integration behavior relies on approval completion.
Technical dependency: A custom module, inherited method, view, field, scheduled job, or API process implements the chain.
This classification exposes missing work. A map that lists routing and permission dependencies but omits audit dependencies could preserve the approval decision while losing evidence of who made it. A map that captures the approval action but not downstream dependencies could allow a transaction to proceed incorrectly after approval.
For each dependency, assign an owner and a migration treatment. The treatment should be one of four choices: migrate as-is, reconfigure in the target version, replace with standard Odoo behavior, or retire after business confirmation. Do not assume that every existing customization deserves to be rebuilt. Existing logic may duplicate capabilities available in the target Odoo environment, while other logic may be essential to the business process.
What Changes Between Odoo Versions or Environments?
Odoo approval behavior can change when the underlying version, installed modules, security model, or customization framework changes. A version upgrade and a migration from another ERP are not identical projects, but both require dependency analysis when approval behavior must remain reliable.
Review these areas before selecting the target configuration:
Module behavior. Standard approval features, field names, models, and settings can differ by Odoo version or installed application. Confirm the target module is available and that its behavior supports the intended chain.
Custom code compatibility. Custom modules often depend on model names, method signatures, view structures, or fields that change between versions. Odoo upgrade tooling handles standard modules and data, but custom modules and business-specific validation require separate review.
Security structure. User groups, access rights, and record rules need comparison between source and target environments. A group with a similar name is not proof that it grants the same effective permissions.
Company and organization structure. Multi-company rules, departments, warehouses, journals, analytic accounts, and operating units can affect approval routing. Preserve the relationships, not just the individual records.
Data and configuration identifiers. External IDs and technical references help connect migrated records to target configuration. If identifiers are regenerated or mappings are incomplete, automated actions and integrations may reference the wrong object.
Integration endpoints. Approval completion may trigger an API call, export, webhook, or document creation. Confirm endpoint behavior, authentication, error handling, and ownership before enabling production automation.
The Odoo upgrade services information from our team addresses the distinction between standard upgrade tooling and the custom modules, third-party applications, integrations, and business checks that still need attention. That distinction matters when approval chains appear intact but fail under real user actions.
How Do You Test Approval Dependencies Before Go-Live?
Test approval dependencies with business scenarios, role-based access, negative paths, and migrated data. A test that confirms only that an administrator can approve a document is not sufficient.
Build a test matrix that covers the conditions most likely to alter the route. Include values below, at, and above each threshold. Test each relevant company, department, category, currency, and approval role. Include users who should approve, users who should not approve, and users who should see the record but lack authority to act.
The test plan should include:
A standard approval that follows the expected route.
A transaction that should not require approval.
A transaction that requires multiple sequential approvals.
A rejection with a reason and resubmission.
A material edit after approval, such as a changed amount or supplier.
A missing approver, inactive user, or changed group membership.
A multi-company transaction viewed by the wrong company context.
A notification failure or unavailable integration.
A historical record whose approval evidence must remain readable.
A downstream action that should remain blocked until approval completes.
Use migrated data for acceptance testing rather than only newly created test records. Historical records may contain old users, inactive departments, archived products, changed currencies, or references to custom values. Those conditions reveal whether the target environment preserves operational history as well as new transaction behavior.
Record expected and actual outcomes for every scenario. A useful test result includes the source record reference, target record reference, test user, company, triggering values, approval sequence, notifications, state transitions, and downstream action. This gives the business a defensible basis for signoff.
Our Odoo migration planning process emphasizes staged review and end-to-end workflow verification because record-level validation does not prove that connected processes still operate correctly. For approval chains, the final test should follow the transaction from trigger through completion.
Common Mapping Mistakes to Avoid
The most damaging mistakes happen when teams treat approvals as a small configuration task instead of a connected control system.
Mapping labels instead of logic creates false confidence. “Finance approval” does not identify the threshold, company, group, or condition that activates the step. Capture the technical and business meaning together.
Testing only the happy path misses rejection, resubmission, edits, escalations, and missing-user conditions. Approval chains are defined as much by what they block as by what they allow.
Using administrator access for validation hides record-rule and group issues. Test with the same role categories that will operate the target environment.
Ignoring historical approval evidence risks losing the audit trail needed to understand past decisions. Determine whether approval records, messages, timestamps, attachments, and rejection reasons must remain accessible.
Rebuilding every customization automatically increases migration scope without proving business value. Compare each customization with target-version capabilities and document the reason for retaining it.
Enabling automation before reconciliation can send notifications, create downstream records, or call integrations against incomplete data. Keep production-triggering actions controlled until configuration and migrated records are validated.
Treating approval as complete when the button works overlooks downstream behavior. Confirm that approval releases the intended next action and does not bypass a required control elsewhere in the process.
A Practical Deliverable for the Migration Team
The final dependency map should become a working migration and testing document, not a static diagram. Give each approval chain a unique identifier and connect it to the business process, Odoo model, source configuration, target configuration, test cases, owner, and signoff status.
A concise deliverable usually contains:
Approval chain name and business purpose.
Source and target Odoo versions or environments.
Trigger fields, thresholds, domains, and company conditions.
Approver logic and required user groups.
Access rights and record rules.
Automated actions, server actions, activities, and email templates.
Custom modules, inherited views, fields, and integrations.
Historical data requirements.
Migration treatment for each dependency.
Test scenarios, expected outcomes, defects, and approvals.
Keep a separate decision log for unresolved questions. Examples include whether a department manager or named user should approve, whether edits should reset an approval, whether historical approvals need to remain actionable, and whether an old customization should be replaced with standard Odoo behavior.
If you need help translating this map into a migration plan, contact our Odoo team with the approval processes, Odoo version details, and customizations you need to evaluate.
Make the Next Migration Step Specific
Start with one approval chain that affects a meaningful transaction, then trace it from its trigger through its final downstream action. Document the people, groups, fields, rules, automation, custom code, integrations, and historical evidence involved. That first map gives the migration team a concrete basis for estimating work and deciding what belongs in the target Odoo environment.
From there, validate the highest-risk chains with migrated data and real user roles before production cutover. If the dependency map reveals unclear routing, overlapping rules, or custom behavior that needs technical review, talk with Versich about your Odoo migration requirements. A clear next step is to turn the map into a controlled migration, test, and signoff plan.
