Performance tuning

Salesforce is a multi-tenant SaaS platform that enforces certain guidelines to ensure that one user/organization’s use does not cause bottlenecks for other tenants that co-exist on the same server. These guidelines are enforced through a set of governor limits that define how fast, how much, and how frequently we can read/write data in Salesforce using APIs.

Bulk APIs is a family of APIs that are custom built for large data transfer. Using these APIs, Delphix CC reads data in bulk, masks them in memory, and uploads them to Salesforce in batches. These batches are then queued and processed by Salesforce.

Refer to Appendix – Governor Limits for more information on Salesforce Governor Limits.

The following are the best practices for optimizing the masking performance.

1. Disabling Metadata Components

Metadata components (packages) such as triggers, workflows, validation rules, and process builders can interfere with data updates and should be reviewed or disabled before masking. Delphix recommends disabling these components before masking, either by using Delphix Rehearsal tool or using your org’s internal tools/processes.

To learn more about Delphix Rehearsal Tool, refer to Appendix – Delphix Rehersal Tool.

2. Serial versus parallel processing

Salesforce Bulk API supports two concurrency modes—parallel and serial—which determine how batches within a Bulk API job are processed. These modes define both the number of batches that can be executed simultaneously and the order of processing. To configure the Bulk API to use parallel concurrency mode, include the following parameter in the JDBC connection string:

BulkAPIConcurrencyMode=Parallel

3. WaitForBulkResults

In Salesforce, the WaitForBulkResults property determines whether the application waits for a bulk operation to complete before proceeding. When set to true, it waits for processing and returns detailed results. When set to false, the application continues without waiting for the results.

4. API limits

API limits define the maximum number of API calls your Salesforce org can make within a 24-hour period or over shorter intervals, depending on the limit type. These limits are in place to ensure fair usage across Salesforce’s multi-tenant environment.

5. Batch Limits

Salesforce limits each batch to 10,000 records and allows up to 25 concurrent batches per org. These constraints must be considered when configuring masking jobs to avoid errors, throttling, or failures.

Delphix tuning uses commit size (records per batch) and thread count (concurrent batches) to optimize performance while staying within Salesforce limits.

6. Threads and Commit Size in Salesforce Compliance

In Salesforce Compliance, commit size defines the number of records per batch, while threads control the number of concurrent batches processed. For example, a commit size of 250,000 with 1 thread results in 25 batches of 10,000 records (Salesforce’s batch limit), but only one batch is processed at a time, reducing throughput.

In contrast, a commit size of 10,000 with 25 threads sends 25 batches concurrently. As each batch completes, another begins, maintaining continuous processing. If thread count exceeds Salesforce’s 25-batch concurrency limit, excess batches are queued until resources are available.

Tuning these parameters—commit size and thread count—effectively balances performance with Salesforce limits. Increasing thread count while maintaining a moderate commit size significantly improves Records Masked Per Minute (RPM), whereas a single thread with a large commit size leads to slower performance. This highlights the value of parallelism in maximizing throughput.

However, running many batches in parallel may introduce record locking issues, especially when masking interdependent objects (e.g., parent-child relationships or shared lookups). In complex orgs, careful planning is essential to avoid data integrity conflicts and batch collisions during masking.

7. Batch limits to consider

Salesforce enforces a 15,000-batch limit per rolling 24-hour period. This allocation is shared between Bulk API(v1) and Bulk API 2.0, so every batch that is processed in Bulk API or Bulk API 2.0 counts towards this allocation.

8. Bulk API and Bulk API 2.0 Limits and Allocations

When masking objects with numerous algorithm assignments, the Salesforce Bulk API file size limit (10 MB) may be exceeded. In such cases, the masking logs may display an error like:

InvalidBatch: Attached file is too large: request.txt. Maximum bytes per file is 10485760 (10 MB).

To resolve this, reduce the commit size in the masking job. This decreases the size of the request.txt file, helping ensure it stays within the Bulk API’s file size limit.

9. Parent Child relationships

In Salesforce, parent-child relationships define hierarchical connections between objects and are critical to maintaining data integrity during masking. There are two primary types:

  • Lookup Relationships – A loosely coupled connection where the child record can exist independently of the parent.

  • Master-Detail Relationships – A tightly bound relationship where the child is dependent on the parent, inheriting behaviors such as ownership and cascading deletes.

When masking, these relationships must be carefully managed to preserve referential integrity. Simultaneous updates to related records—particularly in parent-child structures or shared lookup fields—can result in Row_Lock issues due to record locking.

To mitigate this risk, it's recommended to coordinate with the customer's Salesforce Administrator and avoid masking both parent and child records in the same operation.