Optimizing Zapier tasks for course completion data integration with Salesforce

Hi ​@Danny93 

For us to have more context, post screenshots showing how your Zap steps are outlined to see if we can offer suggestions for how to optimize.

Don’t forget about the ROI of automation: 

Good call ​@Troy Tessalone! Here is a screenshot of that flow. I tried to label each step as best I could!

To cut down on the number of records I got back I created a zapier table to get the unix value of the last time this process was run, use that as a parameter for my rest call in Step 3. I use a code snippet to find the largest value then update the table with that value for the next run (Step 6). The filter step in Step 5 is used to make sure that I am not updating the table with a 0 value incase no results are returned.

The looping seems to be where most the tasks are used but open to feedback!

​@Danny93 

You could combine steps 3-4 into 1 code step, since the code can make the API request and handle the response.

 

You can combine steps 9-10 into 1 code step to do the API request/response.

zapier looping through each record like that is gonna burn through tasks fast, especially with 60 daily completions. the non-obvious risk here is hitting zapier's task limits before you even get the data right, and then paying for overage or having it just stop mid-run.

honestly, i'd flip the approach. instead of fetching course name and username per loop, batch that data upstream. if your lms can dump a daily csv or a single api call with all 60 completions at once, you can use zapier's code step to parse it in one shot. then do a single bulk upsert to salesforce. that kills the per-record loops.

it depends on whether your lms has a "get all completions since yesterday" endpoint or a webhook that sends a batch. if not, you're stuck with the loop but you could cache the course names in a lookup table inside zapier to save one api call per record.

what does your lms actually support for bulk export?

Hey ​@Danny93 👋 How did you get on with Troy and Fabi.SPL’s suggestions?

Let us know if you got it sorted or if you could do with some more help reducing your task usage!

One more lever on top of consolidating those API calls into Code steps: the course name lookup is almost certainly repeating. Sixty completions a day across a much smaller set of courses means you are fetching the same course names over and over.

Pull the course list once at the top of the run into a dictionary inside a Code step, then resolve names from memory during the loop. Same idea on the Salesforce side, one SOQL query with an IN clause over all the usernames returns every contact id in a single call instead of one search per record.

That turns a per record fan out into roughly two reads plus the writes, which is where your task count actually lives. The loop then only does work that genuinely differs per record.

The saved timestamp in step 6 should move only after every Salesforce write in that page succeeds. Otherwise one partial failure advances the cursor and the missed completions never appear on the next run. I would fetch a bounded page, upsert by a stable completion ID, confirm the page, then commit the cursor. Add a small overlap window to the next read and deduplicate by completion ID so late or out-of-order LMS events are still caught.

Coming from Boomi you will recognise this one: the loop itself is not really the cost, the per record round trips are. Two changes usually take this from hundreds of tasks a day down to single digits.

First, drop the contact lookup. If the LMS user id is stored on the Contact as an External ID field in Salesforce, you can upsert straight against that field (PATCH to /sobjects/Contact/LMS_User_Id__c/theValue), so there is no search step and no contact id to carry through the loop.

Second, send one request instead of sixty. The composite sObjects endpoint (/services/data/vXX.X/composite/sobjects) takes up to 200 records in a single call, and allOrNone set to false lets the good rows land while you log the failures. The run then becomes: schedule, one code step that pulls completions since your stored unix value, one code step that builds and posts the composite payload, one step to update the table. Four tasks a day whether there were 6 completions or 600.

Worth keeping the per record path around for odd retries, but as the exception rather than the main flow.