TutorialKart.comSalesforce Integration is the process of connecting Salesforce.com with external systems and applications such as Facebook, Linkedin, Gmail, Outlook, HubSpot, Heroku, SAP, Oracle, Microsoft, WordPress CMS, external websites, middleware platforms, data warehouses, and other business applications. The goal is to let Salesforce and the external system exchange data, trigger business logic, or display information in one user experience.
In this Salesforce tutorial, we learn how to integrate Salesforce to external systems and applications and SOAP api Salesforce. In Salesforce integration, we have to understand different layers and integration features. A good integration design starts by deciding whether the requirement is about user interface, business logic, data access, real-time synchronization, or secure API access for an external client application.
Salesforce Integration Layers for External Applications
Most Enterprise-level applications have to integrate with other external third party applications. Salesforce Integration can be done on the different layers and integration features available at each level for an enterprise application. They are
- User Interface
- Business logic and
- Data.
| Salesforce integration layer | What it solves | Common Salesforce options |
|---|---|---|
| User Interface Integration | Show another application or external content inside the Salesforce user experience. | Lightning pages, embedded web apps, canvas-style experiences, links, and custom UI components. |
| Business Logic Integration | Run a business process across Salesforce and another system. | Apex REST services, Apex SOAP web services, Apex callouts, Flow with callouts, platform events, and middleware orchestration. |
| Data Integration | Move, synchronize, or access data between Salesforce and external systems. | REST API, SOAP API, Bulk API, Composite API, Streaming API, Change Data Capture, and Salesforce Connect. |
User Interface Integration in Salesforce for External Apps
User Interface : User Interface Integration is one great way to surface various applications inside Salesforce with little redesign of each individual app. It provides users a single point of entry into multiple applications like Facebook, Linkedin, Gmail, Outlook, WordPress CRM etc.
This approach is useful when users need to see information from another system while working in Salesforce, but the external data does not need to be copied into Salesforce. Examples include showing an order tracking page, displaying a billing portal, opening a document management screen, or linking to an external service desk application from an Account or Case page.
- Use UI integration when the main need is user convenience, not data storage.
- Confirm authentication and session behavior before embedding an external application.
- Avoid exposing sensitive external pages inside Salesforce unless access control is clearly defined.
- Keep the user experience simple so users understand which system owns the displayed data.
Business Logic Integration in Salesforce with Apex, Flow, and Callouts
Business Logic : Business Logic Integration uses Apex Web Services for Inbound and Apex Callouts for Outbound. Business Logic handles a scenario where business logic is spread across several applications to implement the complete end-to-end business process.
- It extends business logic present in Force.com with outside platforms.
- Apex Web Services perform Inbound logic integration.
A business logic integration is used when one system must take action because of something that happens in another system. For example, an external order system may create a Salesforce Case, Salesforce may call a tax calculation service during quoting, or a middleware process may update several systems after an Opportunity is closed.
Apex Web Services allows users to write logic. It requires knowledge of Apex for writing the Apex classes that expose web services to be invoked by client applications. The steps involved are:
- Create a global class.
- Creating an Inner Apex class.
- Create an Apex method.
- In step 4 generate the WSDL (Web Service description Language).
For new integrations, REST-based services are often easier to consume than SOAP services, but SOAP is still used where a formal WSDL contract is required. Flow can also be used for some external service callouts when the integration requirement is suitable for declarative automation. Apex is preferred when the integration needs custom transformation logic, error handling, complex request composition, or transaction-specific control.
Inbound and Outbound Salesforce Integration Patterns
Salesforce integration can be inbound, outbound, or both. Inbound integration means an external application calls Salesforce APIs or Salesforce-exposed services. Outbound integration means Salesforce calls an external system. Many enterprise integrations use middleware between Salesforce and external applications to manage routing, transformation, retries, monitoring, and system-specific credentials.
| Integration direction | Meaning | Example |
|---|---|---|
| Inbound to Salesforce | An external system sends a request to Salesforce. | An ecommerce platform creates or updates Accounts, Contacts, Orders, or Cases in Salesforce. |
| Outbound from Salesforce | Salesforce sends a request to an external system. | Salesforce calls an ERP system to check inventory or create an invoice. |
| Bidirectional integration | Both Salesforce and the external system exchange updates. | Customer master data is synchronized between Salesforce and an ERP or data hub. |
Data Integration in Salesforce with REST API, SOAP API, Bulk API, and Salesforce Connect
Data Integration : Data Integration uses SOAP APIs and REST APIs. It requires no coding and handles data synchronization requirements, where one application in an enterprise acts as the primary source for a particular business object, like Account.
- SOAP API helps to create, retrieve, update or delete records.
- We can maintain passwords, perform searches using SOAP API.
Data integration design depends on the volume of records, the timing of updates, the system of record, and whether data must be physically stored in Salesforce. For small real-time transactions, REST API or SOAP API may be enough. For high-volume record loading or synchronization, Bulk API is usually a better fit. For event-driven updates, Platform Events, Streaming API, or Change Data Capture may be considered based on the requirement.
| Salesforce data integration option | Best suited for | Notes |
|---|---|---|
| REST API | Modern web and mobile integrations that need record-level access. | Common for JSON-based integrations. |
| SOAP API | Enterprise integrations that require WSDL-based contracts. | Useful where strict service contracts are needed. |
| Bulk API | Large data loads, migrations, and high-volume sync jobs. | Designed for processing many records asynchronously. |
| Composite API | Multiple related Salesforce operations in one request. | Helps reduce API round trips for related operations. |
| Change Data Capture | Publishing Salesforce record changes to subscribers. | Useful for event-driven downstream integrations. |
| Salesforce Connect | Accessing external data in real time without copying all records into Salesforce. | Uses external data sources and external objects. |
Salesforce Connect for External Data Sources and External Objects
Salesforce Connect is used when users need to view, search, or work with data that remains outside Salesforce. Instead of copying external records into standard or custom objects, Salesforce Connect maps the external system through an external data source and exposes the data through external objects.
This is useful when the external system is the system of record and Salesforce users only need real-time access to that data. For example, order history may stay in an ERP system, but sales and service users may need to see it from Account or Case pages in Salesforce. In that design, Salesforce Connect can reduce duplicate storage and avoid unnecessary batch synchronization.
- Use Salesforce Connect when external data should remain in the external system.
- Define an external data source to describe how Salesforce connects to that system.
- Use external objects to represent external tables or resources inside Salesforce.
- Review license, adapter, authentication, performance, and reporting limitations before choosing this approach.
External Client Apps and Connected Apps in Salesforce API Integration
When an external application needs secure API access to Salesforce, the integration must be registered and governed. Salesforce has traditionally used Connected Apps for OAuth, SAML, and API access scenarios. Salesforce also provides External Client Apps as a newer framework for third-party applications that integrate with Salesforce using APIs and security protocols.
For an admin or architect, the important point is governance. External access should not be treated only as a technical connection. The integration should define who can use the app, what OAuth scopes are allowed, which policies apply, how credentials are protected, and how the integration can be monitored or revoked when required.
- Use OAuth policies to control how external applications access Salesforce.
- Grant only the scopes required by the integration.
- Prefer named credentials or secure credential management for outbound callouts.
- Review connected app or external client app access regularly.
- Document the business owner, technical owner, and integration purpose.
Choosing the Right Salesforce Integration Approach
The best Salesforce integration approach depends on the business requirement. Do not choose SOAP API, REST API, Salesforce Connect, or middleware only because the tool is available. Start with the integration question: should Salesforce store the data, display the data, trigger a process, receive events, or publish changes to another system?
| Requirement | Possible approach | Reason |
|---|---|---|
| Display external order details without storing all orders in Salesforce | Salesforce Connect | External data can remain in the source system. |
| Create Salesforce records from a website or external app | REST API, SOAP API, or middleware | The external system needs inbound access to Salesforce. |
| Send Salesforce changes to a downstream system | Change Data Capture, Platform Events, outbound integration, or middleware | The downstream system needs to react to Salesforce changes. |
| Load millions of historical records | Bulk API or data loading tool | Large data volumes need asynchronous processing. |
| Call ERP pricing or inventory from Salesforce | Apex callout, Flow callout, or middleware | Salesforce needs a response from an external service. |
Salesforce Integration Planning Checklist Before Implementation
Before building a Salesforce integration, confirm the design details with business owners, security teams, and system owners. Integration issues are often caused by unclear ownership, missing error handling, incomplete data mapping, or underestimating transaction volume.
- Identify the system of record for each business object.
- Decide whether the data should be copied into Salesforce or accessed from the external source.
- Document field mappings, transformations, required fields, and validation rules.
- Choose the authentication method and define API access policies.
- Plan error handling, retries, alerts, and support ownership.
- Check API limits, bulk processing needs, record locking risks, and expected data volume.
- Test with realistic data and concurrent updates, not only with a single sample record.
Common Salesforce Integration Mistakes to Avoid
| Mistake | Why it causes problems | Better approach |
|---|---|---|
| Copying all external data into Salesforce without checking usage | It can create storage, synchronization, and ownership issues. | Consider Salesforce Connect or selective synchronization. |
| Using point-to-point integrations for every system | It becomes hard to monitor and maintain as systems increase. | Use middleware or an integration platform where orchestration is needed. |
| Ignoring API limits and transaction volume | Integrations may fail during peak loads or bulk updates. | Choose bulk, event-driven, or asynchronous patterns where suitable. |
| Hardcoding credentials in code | It creates security and maintenance risks. | Use secure credential management such as named credentials for outbound callouts. |
| Missing error handling and replay strategy | Failed updates may be lost or duplicated. | Design logging, retry rules, and reconciliation reports. |
Salesforce Integration FAQs
What is Salesforce integration?
Salesforce integration is the process of connecting Salesforce with external applications or systems so that they can exchange data, run business logic, or show external information to Salesforce users.
What are the main Salesforce integration layers?
The main Salesforce integration layers are user interface integration, business logic integration, and data integration. Each layer solves a different type of requirement, so the integration method should be selected based on the business need.
When should I use Salesforce Connect?
Use Salesforce Connect when users need real-time access to data stored outside Salesforce and the data does not need to be copied into Salesforce. It works through external data sources and external objects.
What is the difference between REST API and SOAP API in Salesforce integration?
REST API is commonly used for modern web integrations and JSON-based services. SOAP API is commonly used when a WSDL-based enterprise contract is required. Both can create, read, update, and delete Salesforce records when the integration user has the required permissions.
Do all Salesforce integrations require Apex code?
No. Many integrations can use standard APIs, Salesforce Connect, middleware, Flow, or declarative configuration. Apex is used when custom service logic, complex callouts, transformations, or advanced error handling are required inside Salesforce.
Editorial QA Checklist for Salesforce Integration Layers Tutorial
- Confirm that Salesforce integration is explained across user interface, business logic, and data layers.
- Verify that Salesforce Connect is described as external data access through external data sources and external objects, not as a general data copy tool.
- Check that REST API, SOAP API, Bulk API, and event-based options are not presented as interchangeable for every use case.
- Ensure external client app and connected app references are framed around secure API access and governance.
- Confirm that the existing Tutorialkart Salesforce administrator link and integration image URL are retained without changes.
Conclusion : In this Salesforce tutorial, we have learned about different Salesforce Integration layers and integration features. Salesforce integration can be designed at the user interface layer, business logic layer, or data layer depending on the requirement. In our next Salesforce Tutorial, we learn about SOAP API Salesforce basics.