I’m trying to use the automations feature in Tulip to automatically update table records at a given time based on a specific table query. Currently, the Tulip Automations feature only allows me to update a single table record that’s attached to a record ID, and I can’t do this unless I provide the specific record ID. I would like the automations feature to be able to automate, not a single record based on a record ID, but multiple records based on a table query or some other filtering feature. That way, I’d be able to update all records that satisfy the query that I’ve selected. I’m not sure if there’s some way to get around this that I’m not thinking of but if anyone could shed some light on this, I’d greatly appreciate it. Thanks.
Hey Jaylin, this is a real gap and you are not missing anything obvious. Multi-record updates from a query aren’t supported natively in Automations yet.
There is a workaround that gets you most of the way there today. You can create an HTTP connector pointed at your own instance and a connector function that calls GET /api/v3/tables/{tableId}/records with the filters parameter, which takes a list of field/comparison/value objects and returns every matching record along with its ID. Then in your scheduled automation, call that connector function and pass the result into a looping block. Inside the loop, element gives you each record, so you can use the normal Update Table Record action with the ID from the loop.
Two things to take into account before you build it. The API returns at most 100 records per call, so a larger result set needs pagination with offset. And each run times out at 60 seconds, which in practice is the tighter constraint. A single page of 100 updates fits comfortably, but if your query regularly matches more than that I would page across runs rather than nesting loops. Worth reading Automation limits before you build, since the per-workspace caps on API calls and concurrent runs will shape how you schedule it.
Docs for the other pieces: looping in automations and the list records endpoint.
On the feature request itself, querying and aggregating table records directly from automations and functions is something we are actively working on, and this is useful input for it. Worth reading this thread too, it is the same ask from a different angle. If you can share roughly how many records a typical run would touch and how often it would fire, that helps a lot with sizing.
Thanks for the quick response! To answer your question, each run would typically touch about 20 records, likely less. In the future, this number could go up but I don’t think it’ll be close to the 100 record limit.
Also, I forgot to mention that it will be running once a day at midnight.