The integration worked at handover, then the account owner changed or an access credential expired. Nobody knows who reviews the connection or approves changes to its sending rule. Purchasing an Odoo integration requires ownership of daily operation after delivery, beyond knowing who originally wrote the code.
Document operational responsibility separately
Start with the connection's purpose, participating systems and each party's boundaries. One company may build it, your team administer accounts and another supplier control the destination. “We follow up when problems occur” leaves work between organizations unless a follow-up owner and deputy are identified.
This concerns routine operation, access and rules, rather than recreating a record-reconciliation report or API-version migration plan. Ask the supplier to distinguish included recurring activities from incident investigation and new changes, identifying external dependencies and decisions requiring your organization's approval.
A fictional event-preparation portal and Odoo
A preparation-request portal sends agreed data to Odoo. The team discovers that a service account or sending-rule configuration needs attention, but the employee previously responsible has moved on. This educational case describes neither a customer's connection nor an actual outage and requires no API execution to assess a proposal.
In a tabletop discussion, ask who notices approaching access expiry, performs the authorized action, verifies continuity and covers absence. A useful answer connects a role to reviewable evidence, rather than relying on one person's memory of the integration's configuration location.
An integration operations card
Complete one card for each connection with distinct responsibilities. Reference the account or its authorized management location without recording a secret value. A deputy should understand the review task and authority boundary without automatically receiving unnecessary privileges.
| Area | Record | Handover question |
|---|---|---|
| Follow-up | Owner, deputy and agreed cadence | Who covers the owner's absence? |
| Access | Service reference and access-review owner | Who follows expiry and authorized changes? |
| Rules and destination | Configuration reference and approval authority | Who approves condition or address changes? |
| Operational evidence | Last review and unresolved work | How is completed follow-up demonstrated? |
Add escalation when the decision-maker is unavailable and specify what support may do before approval. Appointing a deputy is not unrestricted authorization to modify data. If part of the connection falls outside the contract, identify the responsible organization and your expected coordination role.
Access has a lifecycle
Odoo 19's JSON-2 documentation connects operations to user permissions, record rules and field access, and discusses dedicated service users and key rotation. Name an access-review and transition owner accordingly. A release's credential lifetime or features should not be generalized to every version, hosting arrangement or interface.
“The developer has the key” is insufficient documentation. Establish who reviews continuing access and how an approved transition is confirmed before retiring the previous credential under an appropriate procedure. These are scope and operations questions: this article creates no account or key and provides no live-system access-change procedure.
A configured rule does not prove delivery
Automation-rule documentation describes conditions, actions, webhook destinations and a payload preview. A preview explains configuration; it does not independently establish actual event delivery or reconciliation of every record. Ask the supplier to define verification evidence appropriate to its contracted operational responsibility.
Keep a reference to the latest approved configuration, its change reason and approver. When a destination or condition changes, the owner must know what needs renewed verification and who performs it. This clarifies follow-up boundaries without replacing monitoring or error handling suitable to the project's scale and sensitivity.
What to review before signing support
Examine access and third-party dependencies and Odoo discovery scope. When discussing Odoo services with Nextwave, request an operations card transferable to an owner and deputy, with recurring work, evidence and clear boundaries, without assuming partnership status or uninterrupted connectivity.
Scope sources
Configuration, rotation and access sections of Odoo 19 JSON-2 and integration sections of automation rules were read on 4 November 2026 without executing their commands. Prepared with AI assistance and information and translation review.
