A portal is the part of Odoo your customers, suppliers and dealers actually see. It is also the part most often left at the Odoo default, which is a list of documents and little else.
Portal development is building the pages, the permissions and the things a portal user is allowed to do — without giving anyone a backend login.
Businesses whose customers log into Odoo
An Odoo portal developer builds the pages outside users see when they log in, and the rules that decide what each of them is allowed to see and do. That means custom pages under /my/, record rules that scope data to the person logged in, document sharing by access token, and portal forms that write back into Odoo. It is a mix of backend security work and frontend work, which is why it is a specialism rather than a configuration task.
The test of a portal is not what it shows. It is what happens when a customer changes the record ID in the address bar.
Each of these is portal work rather than website work. Some of it is configuration; where it is, we say so before quoting.
Quotations, orders, invoices, payments, delivery status and support tickets in one place, with only that customer’s records visible. The standard portal does part of this; the gap is usually what you want shown together.
Purchase orders a supplier can acknowledge, delivery confirmations, and bill submission — so chasing happens in the system rather than over email.
Price lists, stock visibility, order placement and claim submission for a dealer network, scoped so each dealer sees their own terms and nobody else’s.
New pages under /my/ for a model Odoo does not expose by default — a service contract, a project milestone, a test report — with the counters on the portal home page updated to match.
Letting a portal user raise a request, update their own details, upload a document or approve something, with validation on the server rather than only in the browser.
Share a single quotation or invoice by a tokenised link that works without an account, and expire or revoke it when it should no longer work.
The part that matters. Scoping every portal-visible model to the logged-in partner, including the ones a custom page pulls in indirectly through a related field.
Your identity on the portal rather than the stock Odoo layout — done by inheriting the portal templates, so an upgrade does not undo it.
Online payment against an invoice or order through a configured provider, and the reconciliation behaviour behind it. See Odoo integration for the provider side.
These settle the scope. Getting them answered before development starts is most of the difference between a portal that launches and one that is quietly abandoned.
A portal user, an internal user, or nobody at all with a shared link. The answer changes the licence cost, the security model and the amount of work — and it is the question most briefs skip.
Not "their own data" — which records, on which models, including the ones reached through a link on a page. Every portal security problem we have been called to fix was a model somebody forgot was reachable.
A read-only portal is a different project from one where a customer can place an order or a supplier can confirm a delivery. Writing back needs validation, an audit trail and a decision about what happens to the record afterwards.
Portal pages are public-facing and hit by people who are not your staff. Queries that are fine for ten internal users are not always fine for two thousand customers on the first of the month.
This is the single most useful fact about Odoo portals, and it decides the shape of a lot of projects. Odoo charges per internal user. Portal users — external people with no backend access — are not charged for, so giving two thousand customers a login costs nothing in licence terms.
That makes the portal the right answer far more often than people expect. We have seen businesses buy internal user licences for staff at a client company, when the work those people were doing was reading their own orders and approving deliveries, which a portal user can do.
It also sets the boundary. A portal user cannot open backend views, so anything that genuinely needs the Odoo back office is not a portal job. Where a request is on that line we say so before quoting, because the cheap answer and the correct answer are not always the same one.
We quote after the four questions above are answered, not before. These are what move the number.
Portal work sits across security and frontend, so it is reviewed by a solution architect rather than signed off by whoever wrote it.
Portals are rarely bought on their own. These are the pages next to it.
Hiring models, what code ownership means, and how to judge an Odoo developer.
The named people who would do the work, with the Odoo areas each one covers.
Custom modules built to survive version upgrades, quoted separately.
Payment providers, shipping and the systems a portal usually has to talk to.
When the portal is one phase of a wider Odoo rollout.
Who watches the portal after launch, and what happens at the next upgrade.
/my/, a QWeb template, a record rule and an entry in the counters on the portal home page. Any model can be exposed this way, including a custom one, provided it carries the portal mixin so it has a portal URL and an access token.The Odoo behaviour this page describes, in Odoo’s own documentation.
Tell us who has to log in and what they need to do once they are there. We will tell you whether the standard portal covers it, what it would take if it does not, and whether a portal user is the right answer at all — and the diagnosis call is free.