I just upgraded to a plan with loops and I was hoping to replace some API calls with a loop for setting values on multiple rows, but I haven’t found a good step-by-step guide for manual triggers.
The use case is changing all the items related to a job, from the job. Here’s what I’ve done so far:
Created a helper table, with the intent to only loop through a small table, figuring that would be faster than looping through the entire items table. (Is that a reasonable assumption?)
Passed the Job ID to the helper table and listed the related Item IDs on rows.
Related the Item IDs in the helper table to the Items table
Set up a Manual workflow to loop through the helper table and set values in the relation to the Items table
Set up an App interaction workflow with a button to trigger the looping workflow.
Nothing is happening in the loop - is this because there are user-specific columns involved (Job ID) in constructing the helper table?
Yes, these are server-side workflows that can’t read user-specific values (which are stored only on your device).
The right way to do this is:
Add a Webhook workflow.
Add a JSON object column in your Jobs table, containing the rowID only.
Add a normal workflow, in which you should have a trigger workflow step. Trigger the Webhook workflow, and tie the JSON object above to the body of the trigger.
Go back to the Webhook workflow, add a Query JSON step to query rowID from the trigger’s body.
Loop through the Items table, in this step I assume you have a Job ID table in there for relations. Filter the loop to only look at rows where Job ID is equal to the query rowID result above. Make sure you change the max rows in the loop to a reasonable number.
Thanks for laying this out. Compared to how I’m currently doing this (joined mutation templates and API) this may or may not be worth pursuing. How would you say these two approaches would compare for
Yes, absolutely. Server-side workflows do not have access to user specific data.
No, not necessarily. You can target the source table directly, and apply filters as necessary, and it should work fine.
Honestly, for this use case, I would most likely still use the API, especially if speed is important. Doing bulk updates is way faster with the API than with workflow loops.
You can use these to pass values to the workflow when it is called.