"Salesforce connector" names five different things, and only one of them is what an enterprise buyer means when they ask your sales team "do you have a Salesforce connector?" Salesforce Connect adapters, External Services and Data 360 connectors are Salesforce features an admin configures inside an org. MuleSoft, Power Platform and similar connectors run in another platform and call Salesforce APIs from outside. The fifth kind is the one the buyer wants. It is your product's own integration, installed or authorized in their org, syncing their objects and custom fields inside their API budget.
For a SaaS company, that fifth kind is a product decision with a long tail. You build it once, then keep it working across every customer org, each with its own objects, field mappings and security review questions. Appnigma's done-for-you integrations service exists for exactly this ("Build your product. We'll build the integrations."). A named integration engineer handles customer-specific logic and ongoing maintenance. Teams that want a native app their buyers can evaluate inside Salesforce use Appnigma's marketplace apps offering instead ("Your product, inside Salesforce or HubSpot.").
Updated October 2026. Checked against the Salesforce Integration Patterns and Practices guide, the Apex Developer Guide, the packaging guides, the Data 360 integration guide and the ISV security requirements. The earlier version listed "Sales Cloud" and "Service Cloud" connectors that are not Salesforce products, used an outdated product name for CRM Analytics, and made delivery-time and security claims with no source. This update maps the real connector types, the buyer's meaning, and the per-org work a SaaS connector involves.
The five things people call a Salesforce connector
Each kind of Salesforce connector runs in a different place, and that decides who builds it and who maintains it. The table below sorts the five by where the code lives.
| Kind | Where it runs | What it does | Who usually builds it | Source |
|---|---|---|---|---|
| Salesforce Connect adapter | Inside the customer's org | Shows external tables as external objects, read live | Salesforce (OData, cross-org, GraphQL, Amazon) or a developer (custom Apex adapter) | Data Virtualization |
| External Services | Inside the customer's org | Turns an OpenAPI spec into typed Apex classes and Flow actions | An admin or developer registering your API | External Services |
| Data 360 connector | Salesforce's data platform | Ingests or shares data with Data 360 (formerly Data Cloud) | Salesforce, or a vendor using the Ingestion API | Data 360 Connectors and Integrations |
| Platform connector (MuleSoft, Power Platform, Google, Boomi) | The other platform's runtime | Calls Salesforce APIs from a flow built on that platform | The platform vendor | MuleSoft Salesforce Connector |
| Your product's integration | Your backend, a managed package, or both | Syncs your data with the customer's objects | You, a unified API or embedded iPaaS vendor, or a delivery partner | Remote Call-In |
Salesforce Connect is the one most often confused with the rest. It "maps data tables in external systems to external objects in your org," and accesses the data "on demand and in real time," per the Data Virtualization pattern. Nothing is copied, so "this solution doesn't consume data storage in Salesforce." CRM Analytics also has data connectors, per the ingestDataConnector reference. They feed analytics datasets, not your customer's operational records.
When your data should stay in your product
Some SaaS data never needs to live in Salesforce. Order history, usage logs and shipment events are big, change often, and only matter one record at a time. Salesforce rates Salesforce Connect "Best" for that case, one of Salesforce's six integration patterns, in its Data Virtualization pattern.
A vendor can ship this as a product. The Apex Connector Framework builds a custom adapter, and external data sources and external objects are packageable in second-generation managed packages, per the 2GP component list. Customers then see your data on their account pages without a sync job. An indirect lookup "links a child external object to a parent standard or custom object," per the Apex Connector Framework examples, so your records can hang off their Account by a shared external ID.
Three constraints shape whether it fits. The first is write access. "By default, external objects are read only, but you can make them writable," per Writable External Objects. Reporting is thinner too, since the pattern lists "Run reports (limited) on external data." And "custom adapters for Salesforce Connect are subject to the same limitations as any other Apex code," per the Apex Connector Framework considerations. If customers need to build reports, automation or forecasts on your data, a sync into standard or custom objects is the better design.
External Services suit the opposite direction, when Salesforce calls your API. Once a customer registers your OpenAPI spec, "objects and operations defined in the external service's registered API specification become Apex classes and methods," per the External Services page. The registration accepts "OpenAPI 2.0.x or OpenAPI 3.0.x" in JSON or YAML, per the ExternalServiceRegistration reference. Publishing a clean OpenAPI spec is one of the cheapest things a SaaS company can do to make its product easy to call from Flow.
What an enterprise buyer means by "a Salesforce connector"
The buyer is rarely asking about Salesforce Connect. They are asking whether your product will read and write their Accounts, Opportunities and the custom objects their admins built over years, without a spreadsheet in the middle. That is what buyers mean by a native Salesforce integration. That usually means four things.
The integration has to handle their schema, not a demo org's. One customer maps your "workspace" to Account, another to a custom Customer__c object with required fields and validation rules. The sync has to run both ways where your product owns some fields and Salesforce owns others, with a clear rule for which side wins a conflict.
It also has to pass their security questions. A security team will ask how your app authenticates, which scopes it requests, and where tokens live. Listing on AgentExchange adds Salesforce's own review. Salesforce Platform API solutions distributed there "must pass our security review," per How the Security Review Works. Salesforce also says customers are "responsible for evaluating the quality, security, and functionality of Partner Applications" in its ISV security requirements. Expect your own questionnaire either way.
Finally, someone has to maintain it after launch. Customers add fields, change validation rules and rotate integration users, and each change can break a sync that worked the day before. This is where a one-off connector turns into a standing engineering cost. Our guide to building a native Salesforce app covers the packaged route, and our comparison of Salesforce integration tools covers the API-only route.
What shipping one connector to many customer orgs takes
A connector that works in your own sandbox is maybe a third of the job. The rest is the same integration running in dozens of orgs that each set their own limits and policies.
Authentication changed in 2026. "Starting in the Spring '26 release, you can't create new Connected Apps. Use ECAs instead," per Salesforce's requirements for connected apps and external client apps. We explain why the New Connected App button is gone separately. An external client app (ECA) is the registration that lets your backend use Salesforce OAuth, and ECAs "can be packaged in first-generation managed packages or second-generation managed packages," per Package Connected Apps in 2GP. The same requirements page applies to partner apps "in use by more than two customer production orgs" and says "partners must enable PKCE," with refresh token rotation and a 30-day idle refresh token limit, all due May 11, 2026. Our post on connecting a SaaS product to many customer orgs with OAuth walks through the flow.
Every call your connector makes spends the customer's API budget, not yours. An Enterprise Edition org gets 100,000 calls plus 1,000 per Salesforce license (and any purchased add-ons) per 24 hours, per API Request Limits and Allocations. That budget is shared with every other integration the customer runs, as our breakdown of Salesforce API limits per customer org shows.
Here is the arithmetic for one customer, worked from those documented numbers. An Enterprise org with 50 Salesforce licenses has 100,000 + 50 x 1,000 = 150,000 calls a day. Suppose your product changes 30,000 records a day in that org.
| How the connector writes 30,000 records | Calls per day | Share of a 150,000 budget |
|---|---|---|
| One REST call per record | 30,000 | 20% |
| sObject Collections, up to 200 records per call | 150 | 0.1% |
| Polling 6 objects for changes every 5 minutes (reads only) | 1,728 | 1.2% |
The first row is how many in-house connectors start, and it is the one that gets a vendor called by the customer's Salesforce admin. sObject Collections update "up to 200 records" per request. For larger loads, "any data operation that includes more than 2,000 records is a good candidate for Bulk API 2.0," per Bulk API 2.0 limits. For reading changes, Change Data Capture lets you "receive near-real-time changes of Salesforce records" instead of polling, per the Batch Data Synchronization pattern. The Pub/Sub API is the single interface for subscribing to those events.
Should a SaaS company build or buy its Salesforce connector?
It depends on how many CRMs you need and how deep each customer's Salesforce goes. Three routes are common, and each is the better choice for a different company.
Building in house fits when Salesforce is your main CRM target and the integration is part of your product's value. You own the code and the roadmap. You also own every customer-specific mapping and the token rules. When a customer's admin changes a field, the fix is yours too. Our post on build vs buy for two-way sync works through that cost.
A unified API or embedded iPaaS fits when you need breadth across many CRMs quickly and most customers use standard objects. These vendors describe themselves as one API or one embedded framework for many systems. Ask each one how it handles custom objects and per-customer mappings in Salesforce, and what you maintain after launch. Our guide to how an embedded integration platform works covers that model.
Having it built and maintained fits when customers need deep, customer-specific Salesforce work and your engineers need to stay on the product. The build can take two shapes. One is an API integration your backend runs. The other is a native app, a managed package installed in each customer's org, which gives buyers something to evaluate inside Salesforce and a listing their procurement team can review. Appnigma's done-for-you service includes platform development, customer-specific logic, backend changes with testing, and ongoing maintenance. With code access, "fixes arrive as pull requests for your review." Teams that want to keep building can use Appnigma's integration infrastructure instead ("Deploy integrations, faster."). It handles app registration and authorization, plus testing and monitoring of each customer's connection.
Mistakes that break a Salesforce connector after customers install it
A SaaS connector that passed every test in a sandbox can still fail in its first months across real customer orgs. Each mistake below traces back to a documented platform rule.
- Writing one record per call. At 30,000 records a day that is 20% of a 50-license Enterprise org's daily allocation. Batch with sObject Collections or Bulk API 2.0.
- Polling when nothing changed. Polling spends calls every interval. Change Data Capture "requires an integration app for receiving events and performing updates in the external system," per When Do You Use Change Data Capture?, which is exactly what your connector is.
- Planning around a new connected app. New ones cannot be created. Register an external client app and enable PKCE before your third production customer, per the ISV requirements.
- Expecting certificates to install with the package. "Certificates aren't packageable," per External Change Data Capture Packaging and Testing. Each customer org needs its own, and your install guide has to say so.
- Shipping an External Services registration without its credential. "Package developers must add named credential components to the External Services registration package," per the 2GP component list.
- Hardcoding field names from your test org. Customers' custom objects and required fields differ, so mapping has to be configurable per org.
Frequently Asked Questions
What is a Salesforce connector?
It is any component that moves data or calls between Salesforce and another system. Salesforce's own kinds are Salesforce Connect adapters, External Services and Data 360 connectors. Platforms like MuleSoft ship their own, and a SaaS product's Salesforce integration is the fifth kind.
Is Salesforce Connect the same as a Salesforce connector?
No. Salesforce Connect is one feature that shows external data as external objects without copying it. Most connectors copy or sync data instead.
Salesforce Connect vs MuleSoft connector vs Data 360 connector, which one do I need?
They solve different problems. Salesforce Connect shows outside data inside an org without copying it. The MuleSoft connector calls Salesforce APIs from a Mule flow, and a Data 360 connector brings data into Salesforce's data platform for profiles and segments.
Can a Salesforce connector sync custom objects both ways?
Yes, if it is built against each customer's schema. Salesforce APIs read and write custom objects like standard ones. The work is per-customer mapping and conflict rules, not a platform limit.
Does a SaaS connector need AgentExchange security review?
Only if you distribute it on AgentExchange. Salesforce reviews listed managed packages and Platform API solutions. Enterprise customers will still run their own security review.
Can Appnigma build our Salesforce connector?
Yes. Appnigma's done-for-you service builds and maintains customer integrations with a named integration engineer. Its marketplace apps offering builds a native managed package with listing preparation and review support.
Related Articles
- Salesforce Integration Tools for SaaS Companies
- How to Build a Native Salesforce App
- How a SaaS Product Connects to Its Customers' Salesforce Orgs With OAuth
- Connected App vs External Client App in Salesforce
- Salesforce Integration Patterns and Best Practices
Sources
- Salesforce Developers, Integration Patterns and Practices, Data Virtualization
- Salesforce Developers, Apex Developer Guide, External Services
- Salesforce Developers, Data 360 Connectors and Integrations
- MuleSoft Documentation, Salesforce Connector
- Salesforce Developers, Integration Patterns and Practices, Remote Call-In
- Salesforce Developers, LWC, ingestDataConnector
- Salesforce Developers, Apex Developer Guide, Salesforce Connect
- Salesforce Developers, Second-Generation Managed Packaging, Components Available in Second-Generation Managed Packages
- Salesforce Developers, Apex Developer Guide, Apex Connector Framework Examples
- Salesforce Developers, Apex Developer Guide, Writable External Objects
- Salesforce Developers, Apex Developer Guide, Considerations for the Apex Connector Framework
- Salesforce Developers, Metadata API Developer Guide, ExternalServiceRegistration
- Salesforce Developers, ISVforce Guide, How the Security Review Works
- Salesforce Developers, ISVforce Guide, Security Requirements for ISV Partners and AgentExchange Solutions
- Salesforce Developers, ISVforce Guide, Secure Your Connected Apps and External Client Apps
- Salesforce Developers, Second-Generation Managed Packaging, Package Connected Apps in 2GP
- Salesforce Developers, Limits Quick Reference, API Request Limits and Allocations
- Salesforce Developers, REST API Developer Guide, Update Records Using sObject Collections
- Salesforce Developers, Limits Quick Reference, Bulk API and Bulk API 2.0 Limits and Allocations
- Salesforce Developers, Integration Patterns and Practices, Batch Data Synchronization
- Salesforce Developers, Pub/Sub API, Get Started with Pub/Sub API
- Salesforce Developers, Change Data Capture Developer Guide, When Do You Use Change Data Capture?
- Salesforce Developers, Apex Developer Guide, External Change Data Capture Packaging and Testing
