Salesforce node - Different number of records between manual & scheduled execution (PricebookEntries)

Questions
,
1

Hi everyone,

I’m running into a strange issue with an n8n workflow that pulls data from Salesforce, and I’m hoping someone can help me understand what’s going on.

Setup:

I’m using n8n to fetch data from Salesforce PricebookEntries.

Observed behavior:

When I run the workflow manually, I get 995 records (expected numbber) from Salesforce.
When the same workflow runs via the Schedule Trigger, I only get 587 records.

This makes me suspect that the scheduled run is not retrieving all pages of data (pagination issue?).

Workflow structure (simplified):

Screesnhot off when it is run via the shedule trigger (too little results):

image
image1580×1135 168 KB

vs. when I execute it manually

image
image1297×999 160 KB

The relevant part of the workflow:

My questions:

Could this be related to pagination not being fully executed in scheduled runs?
Is there any known difference in how n8n handles Salesforce nodes between manual and scheduled executions?
Are there settings (like “Return All”) that behave differently depending on the trigger? - I can’t find anything like that in that node.

What I’ve already checked:

Any ideas or pointers would be greatly appreciated!
Otherwise I will have to try it with a http node.

Thanks in advance :folded_hands:

2

Hi @Njo_D

Doubt it’s pagination. It’s probably just the difference between editor state and production. Manual runs use pinned data/unpublished changes, but scheduled ones don’t.

Give it a quick republish and clear your pinned data. If that doesn’t work, check the execution logs to see if the Salesforce node is getting different inputs in production mode.

4

This is almost certainly a Salesforce API pagination thing, not an n8n issue. The Salesforce node uses the SOQL query endpoint which returns results in batches and I’d bet the scheduled run is timing out or hitting a rate limit before it gets all pages back. Try swapping the Salesforce node for an HTTP Request node hitting /services/data/v59.0/query directly so you can handle the nextRecordsUrl yourself in a loop