I would like to suggest a feature that would allow a user to execute triggers after a certain amount of time with the implementation of a “Named Timer”. This feature would allow a user to set up a “Named Timer” and then configure the trigger actions that will be performed once the timer is completed. The “Start Named Timer” would be available to in the actions section of the trigger logic and only has the inputs of the specific Named Timer and the seconds until actions start. This feature would be used in situations where a developer needed a way to delay an action for a certain time period and then would be able to trigger another event without having to use a sleep action. This could also help with many race conditions when updating and transactions with outside systems is an issue. this would also be very useful when updating visual indicators on the app step. I think this type of feature would be very useful in app development and be hugely beneficial to user of the apps developers build.
Thanks for writing this up — a non-blocking “fire these actions N seconds from now” action is a real gap today, and I can see the pull especially around race conditions with external systems and visual indicator updates where Sleep isn’t a great answer.
One piece of context on why we’ve historically been cautious here: delayed/scheduled actions can make app logic significantly harder to debug. For example:
User action kicks off a delayed trigger that will update field X on record Y in 5 seconds
User clicks a button that immediately updates that same field
The delayed trigger fires and writes based on the state from step 2 — not the state from step 1 (when it was triggered)
Now imagine several of those queued up at once. Troubleshooting “why does this record keep getting overwritten” gets hard fast. It’s the same reasoning behind why we don’t have async actions today — you can currently trust that action 2 in a trigger always runs after action 1 finishes, and losing that guarantee has real cost.
Not a no — just the tradeoff we’d need to design around. So a few questions to help me scope:
One-shot or repeating? My read is you want one-shot (start it, fires once, done) — as opposed to existing Timer Triggers which run on an interval. Correct?
Cancelable? If it’s named, I’d expect you’d also want a “Cancel Named Timer” action so you can abort it before it fires. Is that part of the ask?
What happens on step change or app complete? If the timer is pending and the user navigates away or the app completes, should it still fire, or get dropped?
If you have a concrete scenario or two where you hit this recently, that would help me a ton — the more specific the better. Either drop it here or happy to grab 20 minutes.
Your summary of the request is spot on. I definitely understand that this feature may increase complexity of debugging applications.
The core of this request is to be able to run actions at the app context level asynchronously of other events occurring within the app. A very similar design concept that is currently allowed within Tulip is to use the app to trigger an automation which will run asynchronously of any app actions and once the automation is complete the automation can complete silently or even answer back to the app that it is complete is some way. With this design concept it is hard to alter data within the app context (ie app level variables). I believe that this design concept may have similar risks to the ones you highlighted and should be understood when implementing an architecture like this.
Scope Questions:
Yes, I would envision it to be a one-shot. If given the opprotunitty I imagine you would call a “Named Timer” on completion of a “Named Timer”. This would need to be similar logic to action vs transition logic where transition to another screen trumps the next action. This would mean that any actions ater the call of the next named timer would be cleared out.
I had not thought about the ability to cancel but I think this would be a great feature!
I would imagine that this type of action get treated the same as a base layer trigger. And if there would be a way to configure the response to an app completion I would like to be able to choose.
Use Cases:
I have a machine with attributes and when an attribute changes an automation gets started to transacts some data through a connector functions and completes. The same machine attribute is also tied to a trigger the base layout of an app to retrieve data entered by the automation. This architecture allows the transaction of data without the app having to be open with a base layout trigger. What then occurs is the base layout trigger runs the connector function to get data before the data is transacted by the automation. I would like to delay the retrieval of this information to give the time for the automation to complete.
Another use case from a visual UI perspective. I would like the ability to change colors on the screen shown to the user for a temporary amount of time. This would allow for more custom UI experiences when interacting with the apps. For example, a user would push a button to trigger an action then return a confirmation of the several things that occurred and based on that I can show different colors and messages and would then be able to reset after 5 seconds.
I think people would come up with a lot of good use cases for this as well.
