Jump between apps using Tulip table values as parameters

I have a main app that execute 7 different processes, each process is done by it’s own app, for that I created a table that contain process name, app name and entrance step, this table is shown on user screen (only the process name is shown) than I wanted to enter directly to destination step of app of chosen process from main app step by app name and step name from that table.
After doing all of that I discovered that it’s not possible in Tulip.
There is an option to open app by variable but than the user gets the screen with green button on Begin, I want to save the time of entrance and let the user start working from the wanted start step that is configured in my table (can be first step or 4th for example).
There is a possibility to choose a step by variable but only for current app, not suite to current issue.
So, my workaround solution is to put if condition for each process and use “complete app than change to step” and choose manualy the app and step, not what I ment to do.
Can you suggest a way I can do it more dynamically ?

Amit Berku

Hey @Amit -

There is a feature request in-flight to be able to launch an app by app name and step by step name, this would mean a single trigger transition could support completely dynamic behavior. Right now either the step name, or app name can be driven by a dynamic value, but not both.

Your approach to doing this with separate triggers for each destination app is the way I would approach this right now.


Hi Pete,
As far as I know, if you put transition in a trigger for moving into different app if by app name or by the app step name it is one time touch, you can’t create a trigger that do transition by app name and than make another one for app step name, the second one will never be executed so nice way of thinking, I don’t think it will never work, correct me please if I’m wrong


Hey @Amit -

You are right, there isn’t a way to easily make this completely dynamic (both app and step name) right now, but its something we can add on our end.


@Pete_Hartnett Any update on this feature request?

Hey @jboyle -

No update on this one just yet. I found the first ask for this feature documented in May, and some good discussions where the takeaway was that we needed to implement this feature, but isn’t wasn’t put on the immediate roadmap (next ~3 releases).

As context, if a feature request gets picked up immediately, and is a small ask, it takes ~10 weeks to make it to full release (scoping, scheduled to sprint, engineering work done, code review, QA, staged release). Bigger features often take 3-6mo.

Thanks for your patience,