Feature Request: Minute-Level Automation Scheduler

Product Suggestions
, , ,
1

Overview

Tulip Automations currently support a minimum schedule frequency of 1 hour. While Tulip Table events (record created/updated/deleted) can trigger automations instantly, there is no equivalent backend, sub-hour scheduling for other actions—especially for running connector functions on a cadence like every 5 or 10 minutes.

Today, to meet this requirement, teams keep a Tulip app open and use app triggers with a minimum interval of 30 seconds. This approach is operationally fragile (requires a station to stay on, app to remain open), not scalable, and unsuitable for backend processing.

Proposed Enhancement

Introduce a Minute-Level Automation Scheduler that allows automations to run in the background without requiring an app to be open, with support for:

  • Intervals: 5 minutes, 10 minutes, 15 minutes, 30 minutes.

  • Custom cron-like expressions for advanced scheduling.

  • Ability to invoke connector functions and execute logic reliably.

Benefits

  • True backend operation: No dependency on an open app or active station.

  • Near-real-time integrations: Enable polling/sync every few minutes.

  • Operational resilience: Built-in retries, observability, and governance.

  • Cost & efficiency: Eliminate “always-on app” workarounds.

2

Thanks for this request as well @sagar007

Agreed with you that the “headless app” solution is operationally fragile. We’re working on putting together best practices here.

We had not included per-minute scheduling in Automations yet, as it is a more advanced feature that is easy to accidentally misconfigure, and we want to ensure both Customers and Partners are comfortable building and commercializing the foundational Automations offerings first. We would also like to further invest in Automation error handling before building out more power features like cron-like scheduling expressions.

In the short term, there are a number of workarounds I’ve heard to set up sub-hour scheduling including having e.g. 4 Automations fire hourly at 0, 15, 30, and 45 past the hour to get the quarterly ones. Please note that Automations have some execution delay and advertised limits, so e.g. 5-minute Automations may start running up against the latency and throughput limits. They would also have commercial implications for your team and your customers.

We’d love to chat more about your Automations use cases and near-term solutions and workarounds, including the commercialization aspects. I’ll work with your Partner success manager to set up some time.

-Olga

3

Hi @OlgaStroilova ,

Never thought about this workaround—thanks for sharing!
This approach could definitely be helpful, but it might become challenging to maintain if there are multiple apps involved.

For now, I’m still able to manage this use case by using a timer of more than 30 seconds on the step when the app is open, as it remains maintainable and easier to handle—especially when migrating apps across workspaces or instances.

4

Agreed the short-term workaround for Automations has maintenance costs. We don’t generally advise copying logic, and are working on features like App Function for reducing duplication.

”High frequency triggers” in apps also have some limitations and could in extreme cases impact the performance of your instance, in addition to the inconvenience you mention of having to leave the app open & running while it waits for the next interval timer. I’ll reach out on Monday and propose a time to chat.