In this piece
Odoo customer portal: when to configure, extend or build
Your customer can download an invoice. Now the buyer needs a colleague to approve an order before it is confirmed. Establish which parts of that rule your current Odoo setup can enforce.
Choose an Odoo customer portal extension from the actions and account relationships your customers need. Demonstrate the native journey first. Add a bounded module when the missing rule belongs inside Odoo. Consider a separate portal when the journey spans several systems or needs an independently maintained interface, with the same authorization tests on every path.
Research checked: 5 November 2026. Product facts use Odoo’s official 20.0 documentation source. The distributor scenario and downloadable acceptance matrix are proposed design aids. We did not run these checks against a live Odoo database.
What can the native Odoo customer portal already do?
The native Odoo customer portal supports defined document and self-service actions. Demonstrate them on your installed configuration and version. A different layout may require configuration; another person’s authority over an order changes a business rule. Ask for evidence of that rule before treating either request as a custom development project.
Odoo’s portal documentation lists order, invoice and account actions. Its read/view wording does not mean customers can never act through the portal. The online-signature documentation describes customer quotation confirmation when enabled, while portal account updates cover specific contact, payment and security changes.
These are defined application actions. They do not establish a general right to edit business records or the approval chain your buyer’s organization requires. Ask who performed the action and inspect its resulting record. Then have that person attempt a forbidden operation.
For each requirement, record the native demonstration and remaining gap. Mark an untested feature as untested. “Customer portal included” does not establish who may approve a colleague’s revised order.
Which company and contact relationships must you model?
Model each contact’s role against the customer account and allowed action. Distinguish the Odoo operating company from your customer’s legal entity and branches. A shared email domain or parent contact relationship does not establish the intended authority. Require an explicit account assignment before adding a person to an approval path.
Odoo documents granting and revoking portal access through Contacts. That provides an account-management mechanism. Your acceptance work must still establish which records and actions each invited contact receives in the actual configuration.
Consider an illustrative distributor serving customer accounts A and B. Buyer A prepares purchases for A. Approver A can authorize A’s purchases within an agreed limit. A finance viewer downloads A’s invoices. A regional employee needs an approved relationship with both accounts.
| Role | Allowed scope | Boundary to demonstrate |
|---|---|---|
| Buyer A | Prepare A’s purchase request and see its progress. | Cannot approve their own request where separation of duties is required. |
| Approver A | Approve an eligible, current request for A. | Cannot approve B’s request or a revised version never reviewed. |
| Finance viewer A | Read and download A’s permitted financial documents. | Cannot change an order or fetch B’s attachment. |
| Delegated administrator A | Request or manage the agreed subset of A’s memberships. | Cannot assign a stronger role or another account without separate authority. |
| Regional employee | Use separately approved roles for A and B. | Switching accounts does not carry permissions or draft data between them. |
Account creation and account authorization need different checks. Odoo documents invitation settings and shared accounts across websites in its customer-account configuration. Neither setting proves that the account/action matrix above is implemented. Include support staff and automated integration identities in the same review.
Should you configure, extend or build a separate portal?
Choose the smallest design that can enforce the agreed customer workflow and be maintained by its owner. Configuration fits a demonstrated native capability. An extension fits a missing rule closely tied to Odoo records. A separate frontend fits a broader customer experience whose cross-system behavior and operating costs justify another application.
| Approach | Good reason to choose it | Evidence before approval | Ongoing obligation |
|---|---|---|---|
| Configure the native portal | The installed apps already perform the required actions and relationships. | A complete customer journey plus the relevant denial tests. | Own configuration, invitations, regression checks and support. |
| Extend Odoo | A bounded permission, approval or document rule belongs with the Odoo transaction. | Exact-version module behavior, server-side enforcement and upgrade tests. | Maintain the module through dependency changes and upgrades. |
| Build a separate portal | Customers need one journey across Odoo and other systems, or a separately released interface. | Identity mapping, authorized commands, source ownership and failure recovery. | Operate another application, including its integrations and release controls. |
Hosting can constrain the extension path. Odoo Online excludes custom and Apps Store modules. Use the Online-to-Odoo.sh integration decision for that hosting question, and the existing Odoo API architecture constraints before specifying an external backend.
A separate portal does not automatically remove a difficult rule from Odoo. If an order can also be changed by an internal user, import or integration, a browser-only restriction leaves another path to the same record. Put the invariant where all relevant operations must respect it, and test those paths explicitly.
Ask each bidder to demonstrate the same workflow and exceptions. Our custom-versus-off-the-shelf decision guide covers the wider procurement choice. If Power Pages is another candidate, its external-user cost model is a separate calculation, not an estimate for this Odoo extension.
What makes a customer approval enforceable?
Bind a customer approval to its actor and customer account, including the version of the record being approved. Specify what invalidates that decision. An Approve button is only an interface; the server must verify authority and the current record when it accepts the transition.
Suppose the distributor requires a second person to approve purchases above an illustrative EUR 5,000 threshold. Define whether that amount includes tax, which currency conversion applies, and what happens at exactly EUR 5,000. Decide who may change the threshold and who approves a substitute approver. These are business decisions, not facts Odoo can infer from the requirement “add approvals.”
Now let a buyer submit revision 7 for EUR 5,200. Approver A reviews that revision. Before confirmation, the buyer changes the quantity and creates revision 8 for EUR 6,400. Our proposed rule invalidates the earlier approval and requires another review. The server must compare the approved version with the current one at the point it accepts the transition.
Decide whether rejection permits revision and whether cancellation releases a reservation. An expired delegation also needs a rule for queued actions. Retain the decision with the version reviewed and resulting record reference.
This buyer-side policy differs from the seller’s quotation-signature flow. For a store built on Shopify, use the separate Shopify B2B approval comparison; its platform capabilities should not be assumed to apply to Odoo.
How do you test delegated access before launch?
Test each allowed action alongside an action the same identity must be denied, then inspect the resulting business records. Use a protected test environment and explicit test accounts. Include direct document requests, changed object identifiers, revoked membership and altered approval inputs, rather than relying on which buttons the interface hides.
| Check | Expected result under the example policy | Evidence |
|---|---|---|
| Finance viewer A downloads an allowed A invoice. | The correct document is returned. | Identity, account, record reference and document identity. |
| The same viewer requests B’s invoice or attachment directly. | No document or protected metadata is disclosed. | Response and server-side authorization result. |
| Buyer A submits a request above the threshold. | The request awaits an authorized second person. | Business state and absence of unauthorized confirmation. |
| The reviewed request changes before confirmation. | The old approval cannot authorize the changed version. | Version comparison and new review requirement. |
| An employee loses membership while a session remains open. | The next protected operation respects the revocation. | Revocation time, request identity and denied action. |
| Two approval requests arrive for the same revision. | The operation produces one intended business effect. | Final record state and correlated request references. |
Download the proposed portal permission acceptance matrix. Its checks start as NOT_RUN. Replace the illustrative roles and thresholds with your approved policy, add your installed version and module revision, and attach actual evidence. The file is a test specification, not a security scan.
Apply this policy to whichever approach you choose. Pair each denial with an authorized action that succeeds: blocking every request is not evidence that the portal works. An administrator demo cannot establish customer isolation.
Which system owns documents and failed actions?
Name the authoritative system for each operation and define what the portal shows while that system is unavailable. A customer needs to distinguish a submitted request from a confirmed order. Support needs a way to reconcile an uncertain result without repeating an action that may have completed.
For a multi-system portal, write a small contract per operation: source record identifier, customer account identifier, freshness expectation, allowed command, response states and recovery owner. If delivery status comes from a warehouse system and invoice status comes from Odoo, label the source and update time separately.
Keep document authorization on the download path as well as the page that links to it. Review cached copies, generated PDFs, exports and search results. A carefully scoped order list is insufficient if a later attachment request forgets the account relationship. Assign an owner to customer administration and retain its audit trail.
What belongs in the implementation brief?
The implementation brief should name the complete customer journey, its permission matrix, exceptional states and acceptance evidence. Add an owner for support and upgrades. Use that scope to compare proposals, including their testing responsibilities and recurring work.
- Define the first journey. For example, an invited buyer prepares a purchase, an approver reviews it, and the buyer sees the accepted result.
- Attach the relationship model. Include multiple accounts, delegated administration, departures and temporary authority.
- Specify the invariant. State which changes require reapproval and where every write path enforces that rule.
- Name the evidence. Require repeatable permitted and denied operations, document identity checks and final-record verification.
- Assign ongoing work. Include module or connector upgrades, support access, monitoring and a repeatable release check.
- Retain the handover. Keep source, configuration, account mappings and operating instructions available to the team that will maintain them.
Ask bidders to price the same acceptance matrix. If one quote excludes delegated administration or uncertain-write recovery, record the exclusion before treating it as the cheaper implementation.
What would we build first?
We would first implement one complete customer journey with its permission and failure checks, using the native portal wherever it meets the agreed policy. Extend a demonstrated gap. Commission a separate application when its additional customer experience has a named owner and a credible maintenance plan.
Wavect’s customer portal development service starts from the required customer actions. Bring the actor/account matrix and one failing native demonstration to the scope discussion. Use them to decide what the build must change.