While there’s much we could and will do to improve the core App Trigger editing experience (likely later in 2025), reusable functions is indeed a better path for this pain point and underlying use case of reusable/shared business logic … and the future many have been waiting for.
Hopefully the future will become the present soon - we’re starting to work on Functions in early 2025.
For more details & a sketch of what we’re thinking, see this parallel thread:
Hi @OlgaStroilova , I know that with inception of functions, it will prevent loads of repeated actions but I still believe we need the feature to copy paste triggers from one trigger type to another. Consider the case that I am calling a bunch of functions inside a trigger on a button click. Now if I want to repeat this use case on step timer then I would still need the functionality to copy-paste to avoid doing the whole setup manually.
Thanks @akshay96 . Could you help me understand the use case a bit better?
Our original vision is if you’re repeating logic – ie.. reusing actions or functions - inside a button event and a step timer, you’d call a function that invokes those actions/functions rather than copy-pasting them. Would this solution work for you or is something missing?
Hi,
As much as I know, in Tulip you don’t have the possibility to call functions as you can do in programming languages such as .Net, you can’t write a global function once and call it from several places, because of that, the only way to use a logic from a button and timer is to copy the commands manually and this is a frustrating.
Yes, you are right that you can’t yet call Functions from Functions, but that is on our roadmap vision. Just confirming that the roadmap would satisfy the underlying goal here.
Hi, this functionality is on your roadmap since I’ve began using Tulip, about 4-5 years ago, can you write how much time it will take you to develop such ability ?
Thank you @Amit , acknowledge that it’s taken a while to get to working on Functions, and it’s a much-requested feature that we’re very excited to be able to get out - hopefully soon!
A bit on the Tulip Functions Timeline — We started working on Functions this year, and had Development Early Access out in May. Production Early Access just came out in September, and we’re working on GA now, for early 2026.
If you haven’t yet tried out Functions, please connect with your Customer Success Manager to get the Early Access enabled for your weekly release instance! I’ve also flagged this internally with your Success Manager for follow up.
More details and scope of what’s already out:
Note that Functions EA/GA don’t yet include the ability to call Functions from Functions - i.e. nested functions - which might be what you’re asking for here. Nested functions are one of our top requests for logic, and it would be a followup item to GA.
For timeline of this followup - we’ve actually had a few different followup logic roadmap items, and we’d love your vote on what you’d like to see next! If you’d like to vote, please fill in this form we used at Ops Calling to collect attendee input on What’s Next for Tulip Logic.
This covers Tulip Triggers, Functions, and Automations since we have one team working on all logic areas. We may convert this to a poll in Community later this year, but this way we get your input early!
I would argue there are going to be “functions” that are only relevant within one application (so no pressing need to manage these outside the app as a capital-F Function) but may need to be fired from app and step and widget trigger types, so updating to enable cross-trigger-type copy/pasting would still be helpful to developers even post-Functions. Usually when I have these situations there are minor tweaks to the trigger logic anyway, so copy/paste/edit is going to be easier than trying to perfect a Function and then customize the app triggers anyway around that static function input/output.
I don’t know how much experience you have in developing software in other languages. Most of my work is in SAP ABAP, and there I definitely prefer to use a function to perform some action and multiple calls from multiple places in the program or between different programs. If there are differences in the logic, you pass a “flag” parameter according to which you make the minor changes. But functional work is definitely better than performing the same logic over and over again in multiple places in the application, so I hope that such an option will also be available in Tulip soon.
Function is a great addition as an instance-wide reusable tool. However, I still see the value for cross widget/timer/looper trigger copying. Functions may overlap with some use cases where cross copying is needed, but definitely not all of them.
This can either be for simple tasks that don’t justify creating a new set of functions, or for use cases where the tasks performed in said triggers simply cannot be condensed in one reusable function.
I also see a big benefit for functions in apps. So simply a function is a trigger list to call from any event (button, step, device…). So you don’t need any variable interfaces, because you simply use the in app variables as they are.
Often you simply want to do the exact same thing on different events…