The Four Types of Integration, for SaaS Teams

The four types of integration are data integration, application integration, process integration and user interface integration. Data integration keeps records in sync, application integration lets systems react to each other's events, process integration runs one business workflow across several systems, and UI integration puts another system's screens or data in front of the user. That list is a common industry framing, not a standard. Salesforce's own Integration Patterns guide says its patterns "are classified into three categories," which are Data, Process and Virtual.

For a founder or CTO at a B2B SaaS company, the label matters less than one decision. When an enterprise customer asks for "a Salesforce integration" or "a HubSpot integration," which of the four are they asking for, and where does that code live? A record sync runs on your servers against each customer's org. A screen inside Salesforce has to ship as a native app the customer installs. Appnigma's done for you team builds those customer integrations for SaaS companies, "with custom logic, backend changes, and ongoing maintenance included."

If you came here for the calculus meaning (integration by parts, substitution) or the business strategy meaning (vertical and horizontal integration), this page is about software.

Updated October 2026. Checked against Salesforce's Integration Patterns and Practices guide and its API and packaging docs. HubSpot facts come from HubSpot's developer docs. The earlier version of this post said Salesforce supports "all four types" as if the list were Salesforce's own, and listed "REST APIs and webhooks" as Salesforce's application integration tools. Salesforce has no core platform feature named webhooks. This update adds Salesforce's three-category model, the six named patterns, what each type looks like as a customer-facing integration, and what a managed package can carry for each.

Four lists that all claim to be "the four types"

Search "4 types of system integration" and the top pages give different answers, because each one sorts a different thing. Some sort by what moves between systems, some by how systems connect, and some by which systems are involved. Knowing which list a person is using saves a confused requirements call.

Source	The four (or three) types	What the list sorts by
Common industry framing (this post)	Data, application, process, user interface	What the integration does
Salesforce Integration Patterns guide	Data, Process, Virtual (three)	What the integration does, plus a separate timing axis
Digibee	"horizontal integration, vertical integration, data integration, and middleware integration"	A mix of architecture and purpose
AltexSoft	Legacy system, enterprise application (EAI), third-party system, business-to-business	Which systems are connected
Wikipedia, System integration	Vertical, star, horizontal (ESB), common data format	How the systems are wired

The lists don't conflict once you see they answer different questions. Point-to-point, hub-and-spoke and ESB describe wiring. Data, application, process and UI describe purpose. A SaaS team needs the purpose list first, because purpose decides where the integration runs and who has to install what.

How the four types map to Salesforce's three categories

Salesforce's integration architecture docs don't use the four-type list. They sort integration patterns by type and by timing. The Pattern Selection Guide defines type as "the style of integration: Process, Data, or Virtual," and timing as synchronous (blocking request and response) or asynchronous (a one-way message). The guide names six patterns in its Pattern Summary. The table below places data, application, process and UI integration against them.

Common type	Salesforce category	Salesforce patterns that fit	Typical Salesforce mechanism
Data integration	Data	Batch Data Synchronization, Remote Call-In	Bulk API 2.0 and REST API in, Change Data Capture out
Application integration	Spread across Data and Process	Remote Process Invocation (Fire and Forget), Remote Call-In	Platform Events over Pub/Sub API, Apex callouts with Named Credentials
Process integration	Process	Remote Process Invocation (Request and Reply, Fire and Forget), Remote Call-In	Flows and Apex that call out, external systems that call in
User interface integration	Virtual, plus UI Update Based on Data Changes	Data Virtualization	Salesforce Connect external objects, Lightning Web Components, Canvas

Application integration has no category of its own in Salesforce's model. Event-driven work shows up inside the Data and Process patterns, and the guide's Event Driven Architecture page explains that an EDA "decouples event message consumers (subscribers) from event message producers (publishers)." UI integration splits too. Showing external data inside Salesforce without copying it is Virtual integration, which "removes the need for data replication across systems," per the Pattern Approach page.

One rule from the Remote Call-In pattern shapes every type. "Remote calls to Salesforce are always synchronous request-reply." When your product writes to a customer's org, it waits for the answer, even if your own system treats the work as a background job.

Which type is a customer-facing SaaS integration?

Most published lists assume one company connecting its own systems. A SaaS product is different, because it connects to hundreds of customer orgs, each with its own objects, fields and rules. The same four types still apply, but each one changes shape.

Data integration

Data integration is what most customers mean first. Your product reads and writes accounts, contacts, opportunities and custom objects in each customer's org. For volume, Salesforce says "any data operation that includes more than 2,000 records is a good candidate for Bulk API 2.0," per its Bulk API 2.0 introduction. For changes flowing back to you, Change Data Capture is meant to "update data in an external system instead of doing periodic exports and imports of data or repeated API calls." The hard part is rarely the API. It's that one customer maps billing city and another maps shipping city.

Application integration

Application integration is the event layer. A deal closes in the customer's Salesforce and your product reacts in seconds. Pub/Sub API "provides a single interface for publishing and subscribing to platform events" and change data capture events. On HubSpot, webhook subscriptions "enable your app to receive real-time notifications when specific events occur in a HubSpot account."

Process integration

Process integration means your product takes a step inside the customer's own workflow. On Salesforce that is usually a Flow or Apex action that calls your API. On HubSpot, custom workflow actions let you "integrate your service with HubSpot's workflows." The Pattern Approach page warns that process patterns "can often require complex design, testing, and exception handling requirements." That warning doubles when every customer's workflow is different.

User interface integration

UI integration puts your product's screen inside the CRM, on the record a rep already has open. On Salesforce that means Lightning Web Components placed with Lightning App Builder. The other route is a Canvas app. Salesforce says Canvas "enables you to easily integrate a third-party application in Salesforce." On HubSpot it means app cards that "display on CRM records, preview panels, the help desk workspace, and the sales workspace."

A typical enterprise request bundles two or three of these. "Sync our usage data into Salesforce and show it on the account page" is data integration plus UI integration. That second half can't run only on your servers.

Where the code runs for each type

Where an integration's code runs decides what it costs a SaaS company and who owns it, and the integration type answers most of that. Data and application integration can run entirely on your infrastructure, with each customer authorizing your app through OAuth. Salesforce now points new apps to External Client Apps, which it calls "the new and improved generation of connected apps," per Package Connected Apps in Second-Generation Managed Packaging. Process and UI integration need something installed in the customer's org.

Type	Runs on your servers	Needs a package or app installed in the customer's CRM
Data	Yes, through REST, Bulk API 2.0 and CDC subscriptions	Only for custom objects or fields your sync needs
Application	Yes, as a Pub/Sub API subscriber or webhook receiver	Only if you define custom platform events
Process	Partly, your API does the work	Yes, the Flow action, Apex or HubSpot workflow action
User interface	Your API serves the data	Yes, Lightning Web Components or Canvas on Salesforce, app cards on HubSpot

A managed package can carry the Salesforce pieces of every type. Salesforce's packageable components list includes external data sources, platform event channel members, Lightning Web Components and External Client Apps. Two things never travel in the package. The same page says "packaged named credentials don't include the access tokens or certificates that are needed to perform authenticated callouts," and after installing an external data source "the subscriber must reauthenticate to the external system." Plan an install step for each customer.

This is also where the build route splits. A sync that lives on your servers can be built on shared infrastructure. Appnigma's integration infra lets "each customer authorize their own account from your product, with their connection managed separately." A screen inside Salesforce or HubSpot is a native app, which is what Appnigma's marketplace apps team builds, "a Salesforce managed package or HubSpot app built around your product and customer workflows."

Does Salesforce have webhooks?

Not as a core platform feature. A search of Salesforce's developer docs finds "webhook" only in cloud-specific features such as Retail Cloud inventory events and Data 360 data action targets. The core platform's outbound push options are Platform Events, Change Data Capture and Outbound Messaging.

Outbound Messaging is the closest thing to a webhook. It lets "changes to fields within Salesforce" send "messages with field values to be sent to designated external servers," per the Outbound Messaging page. The same page says it "is part of the workflow rule functionality in Salesforce." For new builds, Salesforce's own Fire and Forget pattern rates process-driven platform events "Best" and workflow-driven outbound messaging "Good."

HubSpot does use the term. Its webhook subscriptions are app-level, and the Webhooks API guide says "any account that installs your app by going through the OAuth flow will be subscribed to its webhook subscriptions." That same guide notes its endpoints "can only be used with legacy public apps," so newer project apps configure subscriptions in the app's files instead.

Mistakes when a SaaS team picks an integration type

Scoping a UI request as a data sync. "Show it in Salesforce" needs a component installed in the customer's org, which adds packaging and, for a public AppExchange listing, a security review.
Building the event layer on outdated pieces. Salesforce calls PushTopic "legacy" and says "consider using Change Data Capture events" instead, per Streaming Event Features. Its UI Update Based on Data Changes pattern page still describes PushTopic, so check the event comparison page before you follow it.
Assuming every edition gets events. "Platform events aren't supported in Professional and Group Edition orgs," per Salesforce's platform event considerations. Check your customer list before you design around them.
One mapping for every customer. Data integration for a SaaS product is per-customer by nature. Hard-coding one object model breaks at the second enterprise deal.
Missing HubSpot's card deadline. HubSpot says "legacy CRM cards will be sunset on November 2, 2026," per its migration guide. A UI integration built on them needs moving to app cards.

Frequently Asked Questions

What are the four types of integration?

Data integration, application integration, process integration and user interface integration. That is a common industry list, and Salesforce's own guide uses three categories instead, Data, Process and Virtual.

What is the difference between data integration and application integration?

Data integration keeps the same records consistent across systems, often in batches. Application integration lets one system react to another's events in near real time, such as Platform Events or HubSpot webhooks.

What are the 4 types of system integration?

It depends on the list. By purpose they are data, application, process and UI integration. By wiring, Wikipedia lists vertical, star, horizontal (ESB) and common data format.

Which type of integration does a SaaS product need with Salesforce?

Usually data integration first, then UI integration once customers want your data on the record page. The data part can run on your servers, while the UI part ships as a managed package.

Can Appnigma build these integrations for us?

Yes. Appnigma's done for you team builds and maintains customer integrations with Salesforce and HubSpot. Each customer "can have different objects, mappings, and workflows." For a native app inside the CRM, see marketplace apps.

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.

What Are the Four Types of Integration?

Four lists that all claim to be "the four types"

How the four types map to Salesforce's three categories