1.1 Full Pull Syncs Taking Too Long
Symptom: BatchAllQBSFCustomersSync (or similar) runs for an extended time or times out.
Cause: The full-pull batches paginate through all QBO records using startposition and maxresults. For a company with thousands of records, each page = one API callout. The page size is controlled by the BatchSize setting.
Tuning recommendations:
|
Setting |
Location |
Default |
Recommended Range |
|---|---|---|---|
|
|
|
|
|
|
WHERE clause |
|
None (all records) |
Add date filters like |
1.2 Individual SF → QBO Syncs Slow
Cause: BatchSFQBCustomerSync (and all SF→QBO batch classes) run with a hard batch scope of 1 — one record per execute() call. This is intentional to stay within Salesforce callout limits (one HTTP callout per transaction).
Each record = 1 batch execution = 1 API call. For 500 records, that is 500 separate batch executions, which Salesforce schedules asynchronously.
This is by design. There is no tuning option for this path. Use the QBO Batch API endpoint (/v3/company/{companyId}/batch) for true bulk operations if needed — this is available as Batch_Endpoint__c in Quickbooks_Credentials__c.
1.3 Webhook Batch Backlog
Symptom: Webhook events arrive faster than batches can process them, causing a growing queue of BatchQBSF*Webhook jobs in Setup → Apex Jobs.
Cause: Each webhook notification spawns a new batch per entity type. Under high QBO activity, this can create many queued batch jobs.
Fix:
-
Check the Salesforce org's Apex Flex Queue limit (up to 100 jobs).
-
If the queue is full, new webhook-triggered batches will fail to enqueue — consider increasing
BatchSizefor webhook batches so each job processes more records per execution. -
As a fallback, trigger a full Sync from QuickBooks from Admin Setup to catch any changes missed due to a backed-up webhook queue.