Salesforce has three types of integration. Its Integration Patterns and Practices guide says its patterns "are classified into three categories," which are Data Integration, Process Integration and Virtual Integration. Every type is then split by timing (synchronous or asynchronous) and by which system starts the call, and those two choices produce Salesforce's six named patterns.
For a B2B SaaS company, the type decides more than the design. It decides whether your integration runs from your own servers against each customer's org, or ships as a managed package every customer installs, and how much of each customer's daily API allocation you use. Appnigma builds these customer-facing integrations. Our done for you team will "Build your product. We'll build the integrations," and our marketplace apps work puts "Your product, inside Salesforce or HubSpot" when the type needs code in the customer's org.
Updated October 2026. Checked against Salesforce's Integration Patterns and Practices guide (Winter '27, API version 68.0), the REST API and Bulk API 2.0 guides, the API limits reference and the second-generation packaging guide. The earlier version listed five types (data, process, user interface, business logic and security) and called that list Salesforce's official breakdown. Salesforce uses three. This update replaces the list, maps the old five onto the real three, and adds per-org API arithmetic and what each type needs installed in a customer's org.
Salesforce's three integration types and the features behind each
Salesforce defines each type by the problem it solves, not by the tool. The definitions below are quoted from the Pattern Approach and the Pattern Selection Guide. The feature column lists what Salesforce rates as the best fit in each pattern page.
| Type | What Salesforce says it is | Salesforce features that carry it | What a SaaS vendor usually ships |
|---|---|---|---|
| Data Integration | Keeps data in two or more systems in sync "so that both systems always contain timely and meaningful data" | REST API, SOAP API, Bulk API 2.0, Change Data Capture | A sync service on your servers that calls each customer org over OAuth |
| Process Integration | A business process that needs "two or more applications to complete its task" | Platform Events, Apex callouts, External Services | Event definitions and callout code in a managed package, plus your endpoint |
| Virtual Integration | Users "view, search, and modify data that's stored in an external system" without copying it | Salesforce Connect and external objects | A data endpoint you host, and an external data source in the customer's org |
Salesforce's Integration Patterns guide adds one rule that matters for vendors. Virtual integration "is always triggered via an event from the Salesforce platform such as a user action, workflow, search, or record update." Your product can't push into a virtual integration. Salesforce asks for the data when a user needs it.
Salesforce also says "Data integration is often the simplest type of integration to implement," and warns it still needs "proper information management techniques." Master data management, deduplication and data flow design are the techniques it names. For a vendor syncing with hundreds of orgs, that line covers the hard part. You don't own any of those orgs' duplicate rules or field definitions.
Are UI, business logic and security integration types in Salesforce?
No. They are real concerns, but Salesforce's Integration Patterns guide doesn't list them as integration types. The common five-type list (data, process, user interface, business logic and security) mixes Salesforce's types with tools and with cross-cutting concerns. Here is where each item on that list sits in Salesforce's three-type model.
| Item on the five-type list | Where it sits in Salesforce's guide |
|---|---|
| Data integration | One of the three types |
| Process integration | One of the three types |
| User interface integration | Not a type. Showing external data in Salesforce is Virtual Integration, and refreshing the screen on change is the UI Update Based on Data Changes pattern |
| Business logic integration | Not a type. Calling an external pricing or fraud service is Process Integration through Request and Reply |
| Security integration | Not a type. The guide covers it in a separate Security Considerations section that applies to every pattern |
Salesforce says this about UI integration directly. Its Purpose and Scope page says "Salesforce allows for user interface (UI) integration" such as mashups, but "such integration is outside the scope of this document." UI integration is allowed, and it isn't one of the three types.
Event-driven integration is the other common addition. Salesforce treats it as an architecture style, not a fourth type. Its Event Driven Architecture section says "Platform Events, Streaming API, and Change Data Capture (CDC)" enable that style, and that specific patterns "are covered in this document as part of the existing pattern structure."
The correction matters when you write a technical plan for an enterprise customer. Their Salesforce architect will read "security integration" as a sign the plan wasn't built from Salesforce's own model. Name the type, the timing and the pattern instead.
How the three types become six patterns
Salesforce's three integration types (Data, Process and Virtual) each split along two more axes. Timing "specifies the blocking (or non-blocking) nature of the integration." Direction is which system starts the call. The Pattern Selection Guide then names one key pattern per combination.
| Direction | Type | Synchronous | Asynchronous |
|---|---|---|---|
| Salesforce calls another system | Process | Request and Reply | Fire and Forget |
| Salesforce calls another system | Data | Request and Reply | UI Update Based on Data Changes |
| Salesforce calls another system | Virtual | Data Virtualization | Not listed |
| Another system calls Salesforce | Process | Remote Call-In | Remote Call-In |
| Another system calls Salesforce | Data | Remote Call-In | Batch Data Synchronization |
Two cells surprise most teams. Virtual integration has no asynchronous option, because the user is waiting for the data. And every call into Salesforce lands in Remote Call-In. The Remote Call-In page explains why. "Remote calls to Salesforce are always synchronous request-reply." Your service can ignore the response to act asynchronous, but the call itself waits. We cover each of the six patterns, with best-fit solutions and limits, in The Six Salesforce Integration Patterns and When to Use Each.
Which type a customer-facing SaaS integration is
Most SaaS integrations start as Data Integration in the inbound direction. Your product reads and writes Accounts, Contacts, Opportunities or custom objects in each customer's org, from your own servers. That is Remote Call-In for small writes and Batch Data Synchronization for volume. Nothing has to be installed in the org except an OAuth app the customer authorizes.
Process Integration shows up when a customer wants something to happen in your product the moment a rep acts in Salesforce. Examples are a quote generated on Closed Won, or a credit check before a stage change. Now Salesforce is the caller, so code has to run inside the customer's org. That code is an Apex callout or a published platform event, and it ships in a managed package.
Virtual Integration shows up when the customer doesn't want your data copied into Salesforce at all. Usage, billing history and large activity logs are typical, and data residency is a common reason. Salesforce Connect "maps data tables in external systems to external objects in your org," and reads them "in real time without making a copy of the data in Salesforce," per the Data Virtualization pattern. You host an endpoint Salesforce can query, and the customer's org needs Salesforce Connect.
Most products end up combining two types. A common first release is Data Integration from your servers. The second release adds Process or Virtual Integration inside Salesforce, once customers ask to see your data on the record page. Plan the second release before the first one ships, because it changes your auth model and your packaging.
What each type costs a customer's API allocation
Inbound Data Integration spends the customer's API requests, not yours. Salesforce says limits "are enforced against the aggregate of all API calls made to the org in a 24-hour period" and "are not on a per-user basis," per the API Request Limits and Allocations reference. Its own example is an Enterprise Edition org with 15 licenses. That org gets "115,000 requests (100,000 plus 15 licenses x 1,000 calls)."
Here is the arithmetic for a 15-license Enterprise Edition org, using only documented limits. Suppose your nightly sync updates 20,000 records in it.
| How your service writes the 20,000 records | API requests used | Share of the 115,000 daily allocation |
|---|---|---|
| One REST update call per record | 20,000 | About 17% |
| sObject Collections, which updates "up to 200 records" per call | 100 | Under 0.1% |
| Bulk API 2.0 ingest job | A handful of job calls | Negligible against requests (Bulk has its own record limits) |
The first row is how many first versions ship, and it competes with every other tool the customer runs against the same allocation. The sObject Collections docs say "the entire request counts as a single call toward your API limits." For larger jobs, Salesforce's guidance is that "any data operation that includes more than 2,000 records is a good candidate for Bulk API 2.0," per the Bulk API 2.0 introduction. Our Bulk API 2.0 guide covers the record and job limits.
Process Integration spends a different budget. Apex callouts run inside the customer's transaction, where Salesforce allows "a maximum of 100 callouts" and a default timeout that "is 10 seconds," per Callout Limits and Limitations. A slow endpoint on your side shows up as a slow save for the customer's rep.
What has to be installed in the customer's org for each type
Salesforce's three integration types differ most for a SaaS vendor on one question, which is what has to be installed in each customer's org. Salesforce's packageable components list includes named credentials, external credentials, platform event channels and external data sources, so each type has a packaged path.
For Data Integration from your servers, the install is an OAuth app. Salesforce says "Connected apps creation is restricted as of Spring '26" and recommends external client apps instead, per its connected apps page. Existing connected apps keep working. Our External Client App OAuth guide walks through the multi-org setup.
For Process Integration, the package carries the callout code, the named credential and any platform event definitions. Two details catch vendors. "Legacy named credentials are deprecated and will be discontinued in a future release," per Get Started with Named Credentials. And "starting in February 2026," named credentials in a managed package "default to developer control," per Package Named Credentials. We cover the setup in named credentials in a managed package. Platform events also have an edition limit. They "aren't supported in Professional and Group Edition orgs," and installing a package that contains them fails there, per the platform events considerations.
For Virtual Integration, the package can carry the external data source and external object definitions. The customer still needs Salesforce Connect in their org, and each customer authenticates to your endpoint after install.
That is the line between Appnigma's offerings. Data Integration run from your side is the work our done for you team and our integration infra handle. Process and Virtual Integration that need a managed package fall under our marketplace apps work, which includes "a native app, marketplace listing preparation, and review support."
Mistakes when choosing a Salesforce integration type
- Planning one record per API call for a bulk sync. It works in a sandbox and fails in the customer org that already runs five other tools against the same allocation.
- Promising a live view of your data in Salesforce, then building a nightly copy. If the customer said "without copying it," that is Virtual Integration.
- Building new UI refresh on PushTopic events because the UI Update pattern page still shows them. Salesforce now says "PushTopic and generic events are legacy products," per Streaming Event Features, and points to Change Data Capture and platform events. See platform events vs Change Data Capture for the trade-off.
- Shipping platform events in a package without checking the customer's edition. Professional and Group Edition installs fail.
- Using Change Data Capture to notify a user. Salesforce says CDC is "intended to keep downstream systems in sync but not individual users," per When to Use Change Data Capture.
Frequently Asked Questions
How many types of integration are there in Salesforce?
Three. Salesforce's Integration Patterns guide classifies its patterns as Data Integration, Process Integration and Virtual Integration, then splits them by timing and direction into six patterns.
What is the difference between data and virtual integration in Salesforce?
Data integration copies records into Salesforce and keeps them in sync. Virtual integration leaves the data in the external system and reads it live through Salesforce Connect external objects.
What is an inbound integration in Salesforce?
An inbound integration is one where another system calls Salesforce. Salesforce's pattern for it is Remote Call-In, which uses the REST, SOAP or Bulk API 2.0 and counts against the org's daily API allocation.
Which Salesforce integration type does a SaaS product need?
Usually data integration first, run from your servers over OAuth. Process or virtual integration follows when customers want your product to react inside Salesforce, and that part ships in a managed package.
Can Appnigma build our Salesforce integration?
Yes. Our done for you team builds and maintains customer integrations with Salesforce and HubSpot, and our marketplace apps work covers the managed package when the integration has to run inside the customer's org.
About the author
Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.
Related Articles
- The Six Salesforce Integration Patterns and When to Use Each
- What Are the Four Types of Integration?
- Platform Events vs Change Data Capture
- Salesforce API Integration Guide
- What Is a Native Salesforce App?
Sources
- Salesforce Developers, Integration Patterns and Practices, Pattern Approach
- Salesforce Developers, Integration Patterns and Practices, Pattern Selection Guide
- Salesforce Developers, Integration Patterns and Practices, Remote Call-In
- Salesforce Developers, Integration Patterns and Practices, Remote Process Invocation, Request and Reply
- Salesforce Developers, Integration Patterns and Practices, UI Update Based on Data Changes
- Salesforce Developers, Integration Patterns and Practices, Data Virtualization
- Salesforce Developers, Integration Patterns and Practices, Event Driven Architecture
- Salesforce Developers, Integration Patterns and Practices, Purpose and Scope
- Salesforce Developers, Integration Patterns and Practices, Security Considerations
- Salesforce Developers, API Request Limits and Allocations
- Salesforce Developers, sObject Collections
- Salesforce Developers, Update Records Using sObject Collections
- Salesforce Developers, Introduction to Bulk API 2.0 and Bulk API
- Salesforce Developers, Callout Limits and Limitations
- Salesforce Developers, Components Available in Second-Generation Managed Packages
- Salesforce Developers, Connected Apps
- Salesforce Developers, Get Started with Named Credentials
- Salesforce Developers, Package Named Credentials
- Salesforce Developers, Considerations for Defining and Publishing Platform Events
- Salesforce Developers, Streaming Event Features
- Salesforce Developers, When to Use Change Data Capture
