Inbound integration in Salesforce refers to scenarios where external systems send data or requests to Salesforce. This comprehensive post is designed to help you make an informed decision based on your unique business needs.

What is Salesforce Inbound Integration?

Salesforce Inbound Integration refers to when an external system sends a request to Salesforce to perform an operation like upserting or reading data. For example:

• Your ERP system creates a record.
• A mobile app collects customer details.
• An old application updates data.

Choosing the right integration method is crucial. This guide explores the different Salesforce Inbound Integration options. It details the differences between REST and SOAP APIs. It also explains when to use Custom Apex Web Services or Middleware.

Inbound Integration Options in Salesforce

Salesforce offers multiple options, and selecting the right one depends on your data needs, security, and the technology in use.

Key Options:

• REST API (Standard, Composite, Bulk, and Custom)
• SOAP API (Enterprise and Partner WSDL)
• Custom Apex SOAP and REST Web Services
• Middleware Solutions (e.g., MuleSoft, Informatica, Dell Boomi)

Using REST API for Inbound Integration

What is the Salesforce REST API?

Salesforce REST API is a lightweight, web-friendly interface. It uses HTTP methods (GET, POST, PUT, DELETE) to perform CRUD (Create, Read, Update, Delete) operations. It primarily exchanges data in JSON format, making it ideal for mobile apps or modern web apps.

When to Use REST API:

1. Real-Time Data Sync: Quickly create or update data.
2. Lightweight Operations: Simplify CRUD operations that don’t need heavy processing.
3. Modern Applications: Systems using JSON over XML.

Types of REST API in Salesforce

1. Standard REST API:
   Uses pre-built Salesforce endpoints like /services/data/vXX.X/sobjects/Account.
   • Use Case: Simple CRUD operations, e.g., creating a record or reading data.
2. Composite API:
   Processes multiple operations in a single API call.
   • Use Case: Linking or updating multiple records at the same time, e.g., creating both Account and Contact in one call.
3. Custom REST API:
   Uses @RestResource in Apex to implement custom business logic.
   • Use Case: When standard REST APIs don’t suffice, requiring custom logic like data validation or processing.
4. Bulk API 2.0:
   Designed to process large datasets asynchronously in batches.
   • Use Case: Mass updates or data migration with thousands or millions of records.

Example Scenario: Imagine a mobile app needing to retrieve and update customer details in Salesforce. The REST API provides a quick, lightweight JSON payload, making it the ideal solution.

Sample Code Snippet:

@RestResource(urlMapping='/customer/*')
global with sharing class CustomerService {
    @HttpGet
    global static String getCustomer() {
        RestRequest req = RestContext.request;
        String customerId = req.requestURI.substring(req.requestURI.lastIndexOf('/')+1);
        Customer__c cust = [SELECT Id, Name, Email__c FROM Customer__c WHERE Id = :customerId LIMIT 1];
        return JSON.serialize(cust);
    }
}

Leveraging SOAP API for Inbound Integration

What is the Salesforce SOAP API?

Salesforce SOAP API is a robust, enterprise-grade interface that exchanges data using XML. It is designed for complex operations requiring strict data structures, strong security, and transactional integrity.

When to Use SOAP API:

1. Complex Operations and Transactions: Ideal for ACID-compliant integration like financial transactions.
2. Older Systems: Best for systems already using SOAP with strict XML schema.
3. Data Structure and Format: When integration need well-defined XML structures for validation.

Types of SOAP API in Salesforce

• Enterprise Web Services WSDL:
  A strongly typed schema for a specific Salesforce org.
  • Use Case: Single-org client applications.
  • Features: Requires updates whenever custom objects or fields change.

• Partner Web Services WSDL:
  A flexible, metadata-driven schema suitable for dynamic applications.
  • Use Case: Multi-org integration.
  • Features: Requires less frequent updates and uses name-value pairs for flexibility.

Custom Apex Web Services for Inbound Integration

What are Custom Apex Web Services?

Custom Apex Web Services let you publish business logic using Salesforce’s API framework. When standard REST or SOAP APIs fall short, you can create custom solutions for complex validation, transformation, or calculations.

When to Use Custom Apex Web Services:

1. Complex Business Logic: Additional processing or validation before data insertion or update.
2. Specific Integration Requirements: When standard APIs don’t fully address your use case.

Sample Custom Apex Web Service:

global class CustomIntegrationService {
    webservice static String processData(String inputData) {
        String processedData = 'Processed: ' + inputData;
        return processedData;
    }
}

Note: Always consider Salesforce governor limits (e.g., the 10MB payload limit) when designing custom Apex web services.

When to Use Middleware for Inbound Integration

What is Middleware?

Middleware solutions like MuleSoft, Dell Boomi, or Informatica act as centralized platforms to connect multiple systems. They handle data transformation, operations, and error logging, making them ideal for complex, multi-system integrations.

When to Use Middleware:

1. Complex, Multi-System Integrations: Connecting ERP systems, Salesforce, and external databases.
2. Data Transformation Needs: Mapping and converting data formats (e.g., JSON to XML).
3. Batch Processing or Scheduled Sync: Asynchronous operations or batch jobs.

Benefits of Middleware:

• Centralized integration management.
• Robust error handling, retries, and logging.
• Simplified maintenance for multi-system integration’s.

Decision Flowchart – Choosing the Right Integration Approach

When deciding which Salesforce inbound integration method to use, ask yourself these questions:

• Real-time vs. Asynchronous?
  • Real-time: Use REST or SOAP APIs.
  • Asynchronous/Batch: Consider Middleware.

• Simple CRUD Operations vs. Complex Transactions?
  • Simple CRUD: Use Standard REST API or Composite API.
  • Complex Transactions: Use SOAP API (Enterprise/Partner) or Custom Apex Web Services.

• Modern (JSON) vs. Legacy (XML) Systems?
  • Modern Applications: REST API is preferred.
  • Legacy Systems: SOAP API is often the best choice.

• Is Custom Business Logic Required?
  • Yes: Build Custom Apex Web Services.
  • No: Stick with standard REST or SOAP APIs.

Best Practices for Salesforce Inbound Integration

1. Security:
   • Use Named Credentials and secure authentication methods like OAuth 2.0 or JWT tokens.
2. Testing:
   • Leverage tools such as Postman for REST API calls and Workbench for SOAP API testing.
3. Performance & Governor Limits:
   • Monitor your API usage and be mindful of Salesforce limits (e.g., daily call limits for REST API).
4. Error Handling:
   • Implement comprehensive error logging and handling, especially when using middleware for complex integrations.

Conclusion

Inbound integration with Salesforce is a critical component for modern businesses seeking seamless data exchange between various systems. By understanding the differences between REST and SOAP APIs, as well as when to leverage Custom Apex Web Services or Middleware, you can design an integration strategy that meets your organization’s needs.

Whether you require real-time data synchronization with a mobile app via the REST API or need to handle complex, transactional operations using the SOAP API, this guide offers valuable insights to help you make an informed decision. Remember, the best approach depends on your specific use case, the technology stack of your external systems, and your security requirements.

If you found this guide helpful, please share it with your colleagues and leave your thoughts in the comments below. Happy integrating!