One Login, Several Companies: Which Business Is Your App Acting For?

If the same team works for several companies in one business app, agree which company owns each transaction before adding a company switcher. Being allowed to see two companies does not mean a new order can use either company's settings interchangeably. The useful requirement is a clear operating context that stays consistent through creation, related documents and later reopening.

This concerns the business issuing the order or invoice, not the company a customer contact belongs to. It also differs from choosing a language, currency or branch. Decide with your advisers which activities belong to which legal entity; a software selector cannot determine that policy for you.

Separate access, visibility and the active company

Start with a fictional employee who can work for Company A and Company B. They might need a combined list of both companies' work, while creating the next transaction for A only. Those are two different choices: the population visible in the list and the company under which a new action takes place.

Ask the developer to show both meanings without relying on a logo colour. The creation screen should identify its owning company, and a combined list should identify the company on each row. Switching the list filter should not silently transfer an existing transaction to another company.

The Odoo 19 multi-company developer guidelines provide a concrete reason to make this explicit. They describe users working in several companies at once and warn about inconsistent relationships that may only surface when one company is no longer selected. This is a documented implementation concern, not a claim that every multi-company app has the same behaviour.

Decide which records are shared and which values vary

A shared catalogue entry does not require every associated value to be shared. Write down which records are common to the organisations, which belong to one company, and which fields have a separate value per company. Do not use a blank owner to mean both “available to everyone” and “not configured yet.”

Odoo distinguishes company-dependent fields and explains that their value is read using the current company. Its example warns that creating a record for B while A remains the main company can still use A's company-dependent values unless the correct context is applied. The developer guidance describes explicitly selecting the intended company in the implementation.

For a commissioned app, turn that distinction into a demonstration. Give an invented shared item different company-specific settings, then create a draft for each company. Inspect the resulting values, not just the heading on the screen. Your chosen fields and defaults are project requirements; the source does not establish which commercial settings your business should share.

Keep related documents company-consistent

An order belonging to one company should not accidentally acquire an invoice belonging to another. If an actual intercompany process is needed, specify its separate documents and handover deliberately rather than treating an inconsistent link as that process.

Odoo's guide describes model and relationship checks that can enforce company consistency on creation and update when configured. That qualification matters: citing the framework is not evidence that every custom relationship has been configured correctly. The same guide notes strict rules around records without an assigned company, so “shared” records need deliberate modelling too.

Have the developer identify which relationships require a common company, which may reference an approved shared record and what happens when a saved draft contains a newly invalid reference. A clear refusal with a correction path is more useful than a document that saves successfully and fails when reopened by a colleague.

Define what a switch does to unfinished work

Agree whether the company is fixed once a draft is created. If a user can change it, specify which dependent fields must be reconsidered and whether existing lines remain valid. Do not promise that changing a single selector can safely move any transaction between organisations.

Also cover work that outlives the current screen. A queued report or document-generation task should retain an explicit intended company rather than accidentally using a later interface selection. This is a recommended implementation requirement, not a feature certified by the cited tutorial.

Confirm company identity again before issuing a customer-facing document. Use approved business details and reviewed accounting rules; neither this checklist nor a successful test establishes legal or tax correctness.

Accept the complete company journey

Use an isolated test system with fictional organisations. Let one user access A and B, create a draft for B while A is the main selection, and inspect every company-dependent value. Attempt a deliberately mismatched related document and verify the agreed refusal. Then reopen the valid B transaction with only B selected and with a B-only colleague.

Repeat with a shared record, a company-specific record and an unfinished draft during a company switch. Record the outcomes in your app acceptance criteria. Keep the access-role table as a separate control: acting for the correct company does not itself grant permission to approve, export or delete.

Bring these examples to a business-app project discussion. The deliverable is consistent company ownership through the workflow, not merely another dropdown in the header.