Odoo Salesforce integration

What an Odoo to Salesforce integration actually does

Salesforce is where your sales team lives: leads, opportunities, forecasts, the story of how a deal was won. Odoo is where that deal becomes real: the confirmed sales order, the stock reservation, the delivery, the customer invoice, the payment. The moment a deal closes, the same customer exists in two systems that were never designed to agree with each other.

An Odoo to Salesforce integration closes that gap automatically. It keeps the customer master aligned, pushes the operational truth Odoo owns - order confirmed, goods shipped, invoice raised, balance outstanding - back into Salesforce where account managers can see it, and does it without anyone exporting a spreadsheet or re-typing a won opportunity into the ERP. Sales stops asking operations “did that order actually ship”, because Salesforce already shows it.

What data moves

Odoo object / event	Becomes in Salesforce	Notes
Company partner (res.partner, is_company)	Account	Matched by a stable External ID; upserted, never blind-inserted
Individual partner / contact	Contact linked to its Account	Parent Account must exist first, so ordering matters
Confirmed sales order (sale.order)	Order (or Opportunity update)	Only on state = sale; draft quotations are not pushed
Order lines (sale.order.line)	OrderItem / OpportunityLineItem	Requires a matching Product2 and PricebookEntry to exist
Product (product.product)	Product2 + PricebookEntry	Price book and currency mapped from the Odoo pricelist
Customer invoice (account.move)	Invoice / custom billing object	Status and amount due surfaced for account visibility
Delivery (stock.picking)	Order fulfilment status field	Sales sees shipped / partially shipped without ERP access

The exact field mapping, the External ID fields, and which side wins on a conflict are agreed once during design and encoded in the pipeline. After that, nobody maps a field by hand again.

The details that break naive syncs

A point-and-click connector or a nightly CSV push gets you a demo that works and a production system that drifts. The expensive parts are specific to this pair:

• Identity and matching. Odoo keys records by an integer database ID that is meaningless in Salesforce, and Salesforce uses its own 15 or 18-character IDs. Neither is a business key. You need a dedicated External ID field on the Salesforce side and a stored cross-reference so an update lands on the right record instead of creating a duplicate. Salesforce upsert exists precisely for this and a naive sync ignores it.
• Referential order. A Contact cannot be written before its Account, an OrderItem cannot exist without a Product2 and a PricebookEntry, and an Order needs its Account. Push objects in the wrong order and Salesforce rejects half the batch. The pipeline has to sequence writes to respect these dependencies.
• Odoo has no webhooks. Odoo does not emit events the way Salesforce does. You read changes over XML-RPC or JSON-RPC and use write_date as a delta marker, which means handling records touched by a bulk edit, an import, or a scheduled action - not just user clicks.
• Currency and price books. Odoo pricelists and res.currency do not map one-to-one onto Salesforce multi-currency and PricebookEntries. Amounts have to arrive in the right currency with the right rounding, or an opportunity value in Salesforce silently disagrees with the order in Odoo.
• API limits and volume. Salesforce enforces a daily API call budget. One REST call per record works in a demo and dies at scale. Volume belongs on the Bulk API 2.0, with backoff on limit errors and partial-success handling so one bad record does not fail the whole load.
• Partial failures. Salesforce Bulk jobs return per-record success. A pipeline has to capture the rows that failed a validation rule or duplicate rule, retry the transient ones, and surface the rest - not silently drop them.

How we build and run it

We treat this as a pipeline, not a scheduled export. Changed Odoo records are read on a schedule via RPC using write_date deltas, validated, transformed into your agreed Salesforce shape, and upserted through the REST or Bulk API by their External ID. Where Salesforce is the source for a given object, Change Data Capture drives the flow the other way. Writes are sequenced so parents exist before children.

The pipeline is idempotent: every record carries a stable identifier and is upserted, so a retry or a re-run updates in place and never spawns a duplicate Account or a second Order. It runs on cloud-native, fully EU-hosted AWS infrastructure, so partner and order data never leaves the EU, which keeps your DPA / AVV and GDPR obligations clean.

Then we keep it running. Monitoring, alerting, incident response, and - critically - watching for Odoo upgrade changes and Salesforce API version deprecations are our responsibility under contract. You get a named owner and an SLA. Revenue operations stops depending on a middleware flow that only one person understood.

When this integration is worth building

If a handful of deals a month cross from Salesforce into Odoo and someone re-keys them in five minutes, that manual step is genuinely fine and we will tell you so. A native connector app may also be enough when your objects are standard and your volume is low.

The integration earns its place when deal volume makes re-keying a real cost, when duplicate Accounts and stale fulfilment status start eroding trust in Salesforce, when multi-currency or multi-company Odoo makes the mapping non-trivial, or when you need the whole thing owned and operated by someone accountable rather than maintained by whoever set up the last automation.