Use Cases¶
Odoo Sync scenarios fall along a spectrum of organisational coupling — from tightly integrated entities that share management, to independent parties that simply share an interest in a common dataset.
Fully Coupled — Single Management¶
Parties operate as a single logical organisation across multiple Odoo instances. They control the same schema, the same topic configuration, and often share ownership of the data itself.
Holding Company Sync¶
A holding company’s five Odoo databases share a product catalogue, customer list, and invoice stream.
Updates flow in real time via a shared swarm.
No XML-RPC scripts, no nightly CSV exports, no reconciliation jobs — just ip.topic records wired to the right models.
Franchise Networks¶
A central Odoo broadcasts qualified leads to 50 independent franchisee databases.
The first franchisee to claim a lead locks it out for all others atomically — the (from_peer, seqno) dedup constraint ensures exactly-once delivery.
Late arrivals receive a failed mapping rather than a duplicate record.
The central office retains full visibility; franchisees operate independently but within the rules the holding company encodes in the schema.
Zero-downtime Migrations¶
A legacy ERP pushes its transaction history as a stream of signed events to a private topic. The new Odoo instance subscribes and reconstructs state asynchronously, at its own pace, without a hard-cutover weekend. The two systems run in parallel until the migration is complete.
Loosely Coupled — Common Stakes¶
Parties are independent organisations with aligned interests in a shared dataset. They control their own Odoo, define their own extensions, but cooperate on the parts of the data that matter to everyone.
Vendor Catalogue Sync¶
A manufacturer publishes its product catalogue, pricelists, and real-time stock availability to a shared topic. Every customer with an Odoo instance subscribes and receives updates the moment the vendor makes a change — no EDI batches, no portal scraping, no manual price-list uploads. Customers always quote from current prices and never confirm orders for out-of-stock items.
The vendor controls what it publishes; each customer controls how the data maps into their own product and pricelist models.
Supply Chain Provenance¶
A batch of speciality coffee travels from farmer to roaster to café. Each Odoo database appends its processing step as a signed event on the same topic. When a consumer scans a QR code, the receiving Odoo fetches a verifiable, cross-database audit trail. No single company controls the history.
Federated Directories¶
Professionals publish signed profiles to a shared topic. Aggregators subscribe and provide search and booking without storing the authoritative data — they are readers, not owners. The professional can revoke or update their profile from their own Odoo, and every aggregator sees the change instantly. This is the architecture that breaks the Doctolib monopoly model.