Composite Batch Requests
In Part V, we focus on Composite Batch requests and explain how MuleSoft Salesforce Integration executes multiple independent operations within a single Composite API call. This approach reduces the number of network calls while keeping each request isolated and predictable.
In Part I, we introduced Salesforce sObjects and common Apex object types. Part II focused on collections for bulk processing, Part III covered record lifecycle operations, and Part IV explained composite requests. Together, these concepts form the foundation for understanding Salesforce Composite Batch execution.
Understanding Batch-Based Composite Calls
Composite Batch requests allow Salesforce to process several subrequests as part of one API call. However, each subrequest runs independently and cannot share data with others in the batch.
Key characteristics of this Salesforce Composite Batch pattern include:
- Execute up to 25 batch subrequests in a single call
- Return all responses and HTTP status codes in one response body
- Count each subrequest against Salesforce rate limits
- Execute subrequests sequentially, in request order
- Prevent data sharing between subrequests
Because of this design, Composite Batch requests work best when operations do not rely on earlier results.
When to Use Salesforce Batch Operations
Salesforce batch operations work well when integrations must perform several unrelated actions efficiently. For example, you might retrieve records, update others, and delete outdated data in one Composite API batch without linking the operations.
As a result, this approach improves performance while keeping execution behavior easy to reason about. In these cases, Salesforce Composite Batch processing offers a good balance between efficiency and clarity.
Batch Request Body Structure
The request body for Composite Batch requests defines the list of subrequests Salesforce executes. Each subrequest specifies its own resource path, HTTP method, and optional payload.
In this Composite API batch model, the request body includes:
- batchRequests
- A list of batch subrequests to execute
- Each entry defines the method, URL, and request body
- haltOnError (optional)
- Stops processing remaining subrequests if one fails
- Defaults to false
By configuring these fields carefully, teams can control how Salesforce batch operations behave when errors occur.
Batch Collection Input Behavior
During batch subrequests execution, Salesforce treats each operation as fully independent. Therefore, a failure in one request does not affect others unless haltOnError is enabled.
Although Salesforce processes subrequests in order, later requests cannot access earlier responses. Because of this limitation, Composite Batch requests should only include operations that do not depend on shared data.
Batch Response Handling
Salesforce returns a single response payload that contains the result of every subrequest. Each result includes its own HTTP status code and response body.
This response format is a core feature of Composite Batch requests and allows MuleSoft to process outcomes efficiently without making additional API calls. Consequently, integrations remain faster and easier to monitor.
Best Practices for Composite Batch Requests
To use Salesforce Composite Batch processing effectively, follow these best practices:
- Group only unrelated operations in the same batch
- Monitor rate limits carefully, since each subrequest counts individually
- Use haltOnError only for critical workflows
- Log responses to simplify debugging and support
These practices apply to most Salesforce batch operations executed through the Composite Connector and help keep integrations reliable over time.
Conclusion
Composite Batch requests complete the Salesforce Composite Connector feature set by enabling multiple independent operations in a single API call. While earlier parts of this series focused on structure, collections, CRUD actions, and composite requests, this final part shows how batch execution fits into the overall integration strategy.
When used correctly, Composite Batch requests reduce network overhead while maintaining clear execution boundaries, predictable behavior, and scalable MuleSoft integrations.