OData Producer
An OData producer is an external system that exposes data through the Open Data Protocol so Salesforce Connect can pull that data into Salesforce as external objects.
Definition
An OData producer is an external system that exposes data through the Open Data Protocol so Salesforce Connect can pull that data into Salesforce as external objects. OData defines a standard URL pattern, a metadata document describing entity types, and CRUD operations expressed as HTTP verbs (GET, POST, PATCH, DELETE). Once an OData producer is wired up, Salesforce treats the external data as if it were native: records appear in list views, on related lists, in SOQL queries, and on Lightning page components, without the data ever leaving the source system.
Salesforce Connect supports OData 2.0 and OData 4.0 producers. The Connect adapter calls the producer's service endpoint on demand whenever a user or process reads or writes an external object, so storage stays in the producer's system and Salesforce only carries metadata and pointer records. This pattern is common for ERP, mainframe, and data-lake systems where the volume is too high or the data sensitivity too tight to replicate everything into Salesforce.
How OData producers integrate with Salesforce Connect
The OData service contract
An OData producer exposes a service root URL (something like https://erp.example.com/odata/v4) and a $metadata document under that URL. The metadata document is XML defining each entity type, its keys, its properties, and the relationships between entities. Salesforce reads the $metadata, generates one external object per entity type, and creates one external field per property. Once the schema is mapped, Salesforce knows how to construct GET requests for list views, $filter clauses for SOQL where-conditions, and POST/PATCH/DELETE requests for create/update/delete actions.
External objects vs custom objects
External objects (suffix __x) look almost identical to custom objects (suffix __c) in the UI, but the storage model is different. Custom object records live in Salesforce; external object records live in the producer. Salesforce only stores the external ID, a cached metadata snapshot, and any local sharing rules. Reads hit the producer in real time (or use a cache if configured). Writes are forwarded to the producer if the OData connection has write enabled and the producer supports the operation.
OData 2.0 vs OData 4.0
Salesforce Connect supports both versions, but 4.0 is the modern standard. OData 4.0 adds richer query options ($expand, $select, $apply), JSON-only response payloads, simpler annotations, and better cross-platform support. OData 2.0 is still common in legacy SAP NetWeaver and Microsoft Dynamics deployments. Pick 4.0 for any greenfield producer; OData 2.0 only when the producer cannot upgrade. The Salesforce Connect adapter translates OData 4.0 features into OData 2.0 calls when the producer requires 2.0.
Authentication options
Salesforce Connect supports four authentication methods to an OData producer: Anonymous (no auth, for public datasets), Password Authentication (basic auth with username and password), Per-User OAuth 2.0 (each user authenticates with their own credentials), and Named Principal OAuth 2.0 (one service account authenticates on behalf of all users). For enterprise data, Per-User OAuth is the most common because it lets the producer apply user-level authorization (a salesperson sees only their accounts in SAP, not the whole list).
Performance and caching
Every read of an external object record makes a callout to the OData producer. List views that show 20 records make 20 callouts. To stay within the Salesforce Connect callout limit (currently 100,000 per hour at the highest license tier), the adapter caches metadata aggressively and the option Pull Through Cache is enabled by default. Cached data is invalidated by the producer's etag or last-modified header; producers without proper cache headers force Salesforce to re-fetch on every request, which kills performance.
Where OData producers fail
The most common failures are missing $metadata endpoints (Salesforce cannot generate external objects without one), inconsistent paging (some producers cap response size at 50 records and use $skiptoken in non-standard ways), and missing $filter support on key fields (which forces full-table scans on every list view). Use a tool like Postman or the OData Workbench to validate the producer's compliance before plugging it into Salesforce Connect. The Trial Adapter on AppExchange helps test producers without a paid license.
How to connect an OData producer to Salesforce
Connecting an OData producer takes three steps: register the external data source, synchronize the schema to create external objects, and add the external objects to page layouts.
- Verify the producer publishes valid OData
Open the producer''s service root URL in a browser or Postman. Confirm the $metadata endpoint returns valid XML and at least one entity type. If the producer fails this check, fix the producer before proceeding.
- Create an External Data Source in Salesforce
Setup > External Data Sources > New. Select OData 2.0 or 4.0 as the type. Paste the service root URL. Pick the authentication method and supply credentials.
- Validate and Sync
Click Validate and Sync. Salesforce calls the $metadata endpoint and shows every entity type. Check the boxes for entities to bring in as external objects and click Sync. Salesforce creates one external object per checked entity.
- Configure external object permissions and page layouts
Update profiles or permission sets to grant Read (and optionally Write) on each new external object. Edit the relevant page layouts to add the external object as a related list or as a tab.
- Test as a user
Log in as a user with the new permission set. Navigate to a record, open the external object related list, and confirm data displays. Open the OData producer logs and verify the expected callouts are coming through.
Modern standard. JSON payloads, $apply support, simpler annotations. Use for greenfield producers.
Legacy version. Common with SAP NetWeaver and Dynamics. Use when producer cannot be upgraded.
Alternative for Salesforce-to-Salesforce. Uses Salesforce''s own OData implementation under the hood.
Fallback when the producer cannot speak OData. Write a Connection class extending DataSource.Connection.
- External objects do not support cross-object formula fields, roll-up summaries, or workflow rules. The data lives outside Salesforce, so platform automations that assume local storage do not apply.
- Reports on external objects are limited to standard report types; no cross-object reporting across external and internal data without CRM Analytics. Plan analytics architecture before relying on external objects.
- Per-User OAuth authentication requires every user to authorize the producer on first access. Plan a user-facing message explaining the OAuth dance to reduce help-desk tickets at rollout.
- The 100,000 callouts per hour limit on Salesforce Connect applies to the whole org, not per user. A busy list view can exhaust the limit during peak hours; cache aggressively or pre-fetch.
Trust & references
Cross-checked against the following references.
- Access External Data with OData AdapterSalesforce Help
- OData DocumentationOASIS OData TC
Straight from the source - Salesforce's reference material on OData Producer.
- Salesforce Connect OverviewSalesforce Help
- Apex Connector FrameworkSalesforce Developers
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What is an OData Producer?
Q2. What does Salesforce do with OData Producer data?
Q3. What's a trade-off?
Discussion
Loading discussion…