Be sure to review our Idea Submission Guidelines for more information!
Submission GuidelinesPlease add either or both
The purpose is to provide a better way to pass data, and thus allow "Action" tool to be used, from interface responses in a previous App chained to the current App.
Use Case:
We had a workflow with 8 TREE tools and 3 of them had significant number of rows associated. This caused frequent failures where the queries getting the multiple layers of data for the TREE would time out.
Through trial and experiment we determined this was the issue by removing TREE tools until we had consistent function.
Most if not all the TREEs and all of the 3 offending TREEs were used to modify FILTER tools, in this case each of those 3 TREEs 3 or 4 Actions driving the same number of FILTERs
So we had to find a way to break up the operation. Ultimately I separated the 3 large volume TREE tools into a separate workflow to run first and then CHAIN to the original flow with modifications to read the responses passed from the new 1st workflow in the chain and replaced the FILTER with JOINs, effectively filtering by JOIN.
This worked but was extra work and it made me think of the many other situations where I would like to take input from an external source and affect a FORMULA or FILTER or a few other tools where an ACTION is best/only way to modify tool configuration at run time.
I think this lack of a way to use an ACTION tool with a "Non-Interface" data source has probably limited the opportunities of Applications.
Given the division of labor in an APP,
there is no way to make a run time ACTION tool as it must do its job before the core job runs.
This adaptation of the TREE tool, which is my preference, or the adaptation of the Text Box tool, offer good solutions that should be fairly simple to code and roll out the the user base.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.