Salesforce Connect supports two types of adapters for External Objects: OData endpoints and custom Apex adapters. Both let you surface external data as External Objects in Salesforce. But they differ significantly in development effort, flexibility, and ongoing maintenance. This page compares the experience of building a custom Apex adapter against using ForceCnx's managed OData endpoint.
How Custom Apex Adapters Work
Salesforce provides a set of Apex classes that let you build custom connectors for Salesforce Connect. The core classes are DataSource.Connection, DataSource.Provider, and DataSource.Table. You write Apex code that implements these interfaces, and Salesforce calls your code whenever a user interacts with the resulting External Objects.
The implementation typically involves three parts:
- Provider class (
DataSource.Provider): Declares the capabilities of your connector — which authentication types it supports, what connection properties it needs, and what data source features it can handle. - Connection class (
DataSource.Connection): The core logic. Implements methods likesync()(returns table and column metadata),query()(executes search and filter requests), and optionallyupsertRows()for write-back. This is where you write the code that calls your external API or database. - Table definitions: Returned by the
sync()method, these describe the schema of your external data — table names, column names, data types, and which columns support filtering and sorting.
When a Salesforce user views an External Object record, Salesforce invokes your query() method with the relevant filter criteria, sort order, and pagination parameters. Your code must translate those into a request to the external system (typically an HTTP callout to an API), parse the response, and return the results as DataSource.TableResult objects.
This all runs within Salesforce's Apex runtime, which means it is subject to governor limits: callout time limits, heap size limits, SOQL query limits, and CPU time limits. Your adapter code executes on Salesforce's infrastructure, not your own.
How ForceCnx Works
ForceCnx uses the OData adapter path instead of Apex. It connects to your PostgreSQL, Google Cloud SQL, or Amazon RDS database, introspects the schema, and generates a managed OData 4.0 endpoint. You configure which tables and views to expose through the ForceCnx web UI, and Salesforce Connect consumes the endpoint using its built-in OData connector.
There is no Apex code involved. The connection is configured entirely through Salesforce's standard External Data Source setup, pointing at the OData endpoint URL and the OAuth credentials that ForceCnx generates. Salesforce handles the OData protocol communication natively.
Head-to-Head Comparison
| Dimension | Custom Apex Adapter | ForceCnx |
|---|---|---|
| Code required | Significant Apex development | No code |
| Salesforce developer needed | Yes — Apex, DataSource API expertise | No |
| Setup time | Weeks to months | Minutes |
| Governor limits | Subject to Apex callout, CPU, heap limits | Runs outside Salesforce, no governor limits |
| Query performance | Limited by Apex callout timeout (120s) | Limited by database query performance |
| Pagination | You implement in Apex | Built into OData endpoint |
| Filtering / sorting | You parse and implement each operator | Full OData query support |
| Schema sync | Manual — update sync() method and redeploy | Automatic from database schema |
| Authentication | You implement in Apex (Named Credentials) | OAuth credentials from ForceCnx dashboard |
| Supported data sources | Any API you can call from Apex | PostgreSQL, Cloud SQL, Amazon RDS |
| Write-back support | Yes — implement upsertRows() | No — External Objects are read-only |
| Testing | Apex test classes required (75% coverage) | No Salesforce code to test |
| Deployment | Apex metadata deployment (change sets, CI/CD) | No deployment to Salesforce org |
| Maintenance | Update Apex on API/schema changes | Managed by ForceCnx |
When to Choose Custom Apex Adapters
Custom Apex adapters have genuine strengths, particularly in flexibility and data source coverage.
When your data source is not a relational database. Apex adapters can call any external API: REST, SOAP, GraphQL, or proprietary protocols. If your data lives behind a custom API, a legacy system with a SOAP interface, or a third-party service, an Apex adapter can connect to it. ForceCnx requires a PostgreSQL-compatible database.
When you need write-back from Salesforce. Apex adapters support the upsertRows() method, which lets Salesforce users create and update records on the external system directly from the Salesforce UI. If bidirectional data flow through External Objects is a requirement, Apex adapters can provide it.
When you need complex data transformation. If the data from your external system needs significant reshaping, aggregation, or merging from multiple API calls before it is presented as an External Object, Apex gives you the flexibility to implement that logic in the adapter itself.
When you want everything inside Salesforce. For organizations that prefer to keep all integration logic within the Salesforce platform — no external SaaS dependencies — Apex adapters keep the code, configuration, and execution within the org. Some regulated industries or security-conscious organizations prefer this model.
When the data source changes infrequently. If the external schema is stable and the integration is simple (a single API with a few fields), the ongoing maintenance cost of an Apex adapter can be manageable.
When to Choose ForceCnx
ForceCnx is the better choice when you are connecting a relational database to Salesforce and want to minimize development and maintenance.
When you do not have Salesforce developer resources. Building a custom Apex adapter requires knowledge of the DataSource API, Apex best practices, governor limit management, and Salesforce deployment workflows. This is specialized expertise that many teams do not have in-house. ForceCnx requires no Salesforce development skills.
When you need to move fast. A custom Apex adapter is a development project: design, build, test (including writing Apex test classes to meet the 75% coverage requirement), deploy through change sets or CI/CD, and validate in production. ForceCnx goes from database connection to working External Objects in a single sitting.
When governor limits are a concern. Apex adapters run inside Salesforce's runtime. Every callout, every byte of heap, every millisecond of CPU time counts against governor limits. For complex queries or large result sets, these limits can be constraining. ForceCnx runs outside Salesforce, so query complexity is limited only by your database's capabilities.
When your database schema changes frequently. Adding a table or column with an Apex adapter means updating the sync() method, updating the query() method, writing new test coverage, and deploying the changes. With ForceCnx, you re-sync the schema in the UI and the new fields appear in the OData metadata automatically.
When you want to keep your Salesforce org clean. Every Apex adapter adds code to your org that must be maintained, tested, and deployed. In orgs with heavy customization, additional Apex classes increase complexity, deployment times, and the risk of conflicts during upgrades. ForceCnx adds no code to your org — just an External Data Source configuration pointing at an OData URL.
When you want predictable performance. Apex callouts have a 120-second timeout limit and share resources with other Apex operations in your org. ForceCnx queries run against your database directly, where you control indexing, query optimization, and resource allocation.
Bottom Line
Custom Apex adapters and ForceCnx both create Salesforce Connect External Objects, but they sit on opposite ends of the build-vs-buy spectrum. Apex adapters give you maximum flexibility: any data source, write-back support, and custom transformation logic, all running inside Salesforce. The cost is significant development effort, governor limit constraints, and ongoing maintenance of Apex code.
ForceCnx gives you a working External Objects integration in minutes with no code, no governor limits, and no Salesforce deployment. The trade-off is that it supports relational databases only and provides read-only access. For teams connecting PostgreSQL, Cloud SQL, or RDS to Salesforce — which is the most common External Objects use case — ForceCnx eliminates weeks of Apex development and replaces it with a managed service that handles the OData layer entirely.