Control Containers & Interface Tools

Hi all,

I'm currently on Version 2023.1.1.200 Patch: 1.

I'm really interested in the Control Container idea, and my imagination went wild with the thought that we could do chain apps within the workflow itself, thereby not requiring two workflows to do the job.

But, to my dismay, the Control Container doesn't accept Interface Tools, and therefore, chain apps cannot be used.

Has anyone tried doing this? Maybe I'm doing it wrong, but the warning sign seems to suggest I cannot do it that way.

Real bummer if that's the case.

Interface Tools

Accepted answers

KGT

I stumbled across this and thought I would add some info even though it's an older thread.

When the interface is established, that is before the workflow runs and hence just uses workflow metadata. The idea of having different interfaces appear upon different options will not be solved by Control Containers.

The only current solution for this other than chained apps, is:

Put those options into an HTML interface on a macro and put those choices into the code.
Or, with Alteryx Server, in a webpage and have the selections there run small jobs via the Gallery API configuring the next option. This is the best option and means it's a lot easier to distribute the usage to more people. But, requires being able to host a webpage (sharepoint/confluence etc is always a good option), and code a webpage (not sure if GenAI could do most of this for you).

Trying to break it down:

When the interface is established it uses the workflow metadata on the front-end, nothing happens in terms of running the workflow. The interface is never then re-established. So, once the workflow starts running, the interface can't change.
I'm sure I've documented this better years ago in relation to users wanting a summarize to update a dropdown (When you run it before saving, the save will then store the metadata from that run and use that to configure the tool, however it will not be dynamic).

The confusion in some of the comments here is the different purposes that people have for Chained Apps. If the chained app is to show a different interface each app, then that will not be solved by Control Containers, however if the purpose is to choose different processing options based on essentially "variables" passed through as data, then that will be solved by Control Containers. As with anything that has been in Alteryx for over 10 years, it's use is varied.

All comments

npariso

I recall them mentioning in the announcement that users would no longer have to build separate workflows for chaining and that the control containers would make it easier. I have tried to do it but failed because of no interface tools.

caltang

Yeah, I was really looking forward to axing all the chain apps. But it seems like they live to see another day…. For now!

caltang

Bumping this thread again, hopefully Alteryx can see this...

flying008

Hi, @caltang

Maybe you can use Control Input anchor to shift your 'chain app' function in the same workflow.

Or you can show a ideal screenshot to explain your want.

caltang

Screenshot 2023-07-12 105333.png

I am simplifying it greatly, but the output tool will contain NAME && VALUE as fields, and it will be referenced in the Drop-Down tool as follows:

Screenshot 2023-07-12 105424.png

By using a control container, then it updates more quickly and dynamically.

Not sure if this helps @flying008

flying008

Hi, @caltang

As help said, Interface tools are not supported inside Control Containers. You can have Interface tools and Control Containers in the same workflow—the Interface tools just can’t be inside the Control Containers.

caltang

Would be cooler if it could tho... Thanks @flying008

NeoInfiniTech

While not entirely related to this, with the addition of Control Containers, one way to make it possible to get rid of the chained apps would be the addition of enabling the user to dynamically modify the parameters of the tools contained in the following control containers (using the output of the previous tools as parameters), as I proposed in this idea: https://community.alteryx.com/t5/Alteryx-Designer-Desktop-Ideas/Dynamic-Tool-Configuration-Change-While-the-Workflow-is-Running/idi-p/1137795

I find myself having to create workflows from a workflow template, in the cases where creating the input of the next analytic app in chain is not enough, and changing the properties of the tools are also necessary (such as "how many columns should the Text to Column tool split the data to", an information I obtained in the previous app but cannot transfer to the next app dynamically without creating app values for example).

While using the interface tools with control containers is possible as mentioned above, especially if you incorporate tabs into your interface design, that alone unfortunately doesn't solve the problem I mentioned above.

In addition to all of this, another problem even the control containers and the idea I proposed above cannot solve is dynamically obtaining the metadata information from a tool in a given control container and allow the user to use that information in the same analytic app interface before the app is run, as if the information was obtained already by running the workflow, which I believe is a problem/request mentioned above.

One idea that comes to mind for the solution of this problem is to introduce a feature to Alteryx Designer where specifying the input files/parameters in the analytic app and clicking the "Refresh Metadata" button that would retrieve this information and allow the user to utilize it, but this would need a structure where the user could select which tools would be run exclusively each time the user clicks the "Refresh Metadata" tool (i.e. right clicking the tool to check a "Treat as Metadata Tool" option), to obtain the necessary information.

The tools selected to be treated as metadata tools could also be modified to select if it will be run with the normal workflow (three options; Run Only with WF, Run Only as Metadata, Run Always), and the metadata behaviour of the tool could be changed, for example read/produce only the first row of the tool result instead of producing the full results when run for refreshing the metadata only.

KGT

I stumbled across this and thought I would add some info even though it's an older thread.

The only current solution for this other than chained apps, is:

Put those options into an HTML interface on a macro and put those choices into the code.
Or, with Alteryx Server, in a webpage and have the selections there run small jobs via the Gallery API configuring the next option. This is the best option and means it's a lot easier to distribute the usage to more people. But, requires being able to host a webpage (sharepoint/confluence etc is always a good option), and code a webpage (not sure if GenAI could do most of this for you).

Trying to break it down:

When the interface is established it uses the workflow metadata on the front-end, nothing happens in terms of running the workflow. The interface is never then re-established. So, once the workflow starts running, the interface can't change.
I'm sure I've documented this better years ago in relation to users wanting a summarize to update a dropdown (When you run it before saving, the save will then store the metadata from that run and use that to configure the tool, however it will not be dynamic).

caltang

I missed this comment but thank you for writing this. It is very clear and explains better.

I eventually settled for a different approach that worked well. But after using control containers for awhile and trying to test it to its limits, what you’re saying is what I learned through brute force haha!

Div

Here is a video that covers everything you need to know about Control Containers:-

https://youtu.be/ovZBB6eyqps

Quick Links

This months top contributors

atcodedog05 19458

Qiu 15866

binu_acs 15708

MarqueeCrew 13708

apathetichell 13703