Alteryx Designer Desktop Ideas

We have discussed on several occasions and in different forums, about the importance of having or providing Alteryx with order of execution control, conditional executions, design patterns and even orchestration.

I presented this idea some time ago, but someone asked me if it was posted, and since it was not, I’m putting it here so you can give some feedback on it.

The basic concept behind this idea is to allow us (users) to have:

• Design Patterns
  • Repetitive patterns to be reusable.
  • Select after and Input tool
  • Drop Nulls
  • Get not matching records from join
• Conditional execution
  • Tell Alteryx to execute some logic if something happens.
  • Record count
  • Errors
  • Any other condition
• Order of execution
  • Need to tell Alteryx what to run first, what to run next, and so on…
  • Run this first
  • Execute this portion after previous finished
  • Wait until “X” finishes to execute “Y”
• Orchestration
  • Putting all together

This approach involves some functionalities that are already within the product (like exploiting Filtering logic, loading & saving, caching, blocking among others), exposed within a Tool Container with enhanced attributes, like this example:

The approach is to extend Tool Container’s attributes.

This proposition uses actual functionalities we already have in Designer.

So, basically, the Tool Container gets ‘superpowers’, with the addition of some capabilities like: Accepting input data, saving the contents within the container (to create a design pattern, or very commonly used sequence of tools chained together), output data, run the contents of the tools included in the container, etc.), plus a configuration screen like:

1. Refers to the actual interface of the Tool Container.
2. Provides the ability to disable a Container (and all tools within) once it runs.
   • Idea based on actual behavior: When we enable or disable a Tool Container from an interface Tool.
3. Input and output data to the container’s logic, will allow to pickup and/or save files from a particular container, to be used in later containers or persist data as a partial result from the entire workflow’s logic (for example updating a dimensions table)
   • Based on actual behavior: Input & Output Data, Cache, Run Command Tools, and some macros like Prepare Attachment.
4. Order of Execution: Can be Absolute or Relative. In case of Absolute run, we take the containers in order, executing their contents. If Relative, we have the options to configure which container should run before and after, block until previous container finishes or wait until this container finishes prior to execute next container in list.
   • Based on actual behavior: Block until done, Cache, Find Replace, some interface Designer capabilities (for chained apps for example), macros’ basic behaviors.
5. Conditional Execution: In order to be able to conditionally execute other containers, conditions must be evaluated. In this case, the idea is to evaluate conditions within the data, interface tools or Error/Warnings occurrence.
   • Based on actual behavior: Filter tool, some Interface Tools, test Tool, Cache, Select.
6. Notes: Documentation text that will appear automatically inside the container, with options to place it on top or below the tools, or hide it.

This should end a brief introduction to the idea, but taking it a little further, it will allow even to have something like an Orchestration layout, where the users can drag and drop containers or patterns and orchestrate them in a solution, like we can do with the Visual Layout Tool or the Interactive Chart tool:

I'm looking forward to hear what you think.

Best

This idea has arisen from a conversation with a colleague @Carlithian where we were trying to work out a way to remove tools from the canvas which might be redundant, for example have you added a select tool to the canvas which hasn't been configured to change a data type or rename a field. So we were looking for ways of identifying in the workflow xml for tools which didn't have a configuration applied to them.

This highlighted to me an issue with something like the data cleanse tool, which is a standard macro.

The xml view of the data cleanse configuration looks like this:

<Configuration>
  <Value name="Check Box (135)">False</Value>
  <Value name="Check Box (136)">False</Value>
  <Value name="List Box (11)">""</Value>
  <Value name="Check Box (84)">False</Value>
  <Value name="Check Box (117)">False</Value>
  <Value name="Check Box (15)">False</Value>
  <Value name="Check Box (109)">False</Value>
  <Value name="Check Box (122)">False</Value>
  <Value name="Check Box (53)">False</Value>
  <Value name="Check Box (58)">False</Value>
  <Value name="Check Box (70)">False</Value>
  <Value name="Check Box (77)">False</Value>
  <Value name="Drop Down (81)">upper</Value>
</Configuration>

As it is a macro, the default labelling of the drop downs is specified in the xml, if you were to do something useful with it wouldn't it be much nicer if the interface tools were named properly - such as:

So when you look at the xml of the workflow it's clearer to the user what is actually specified.

I think we can all agree that Workflow Summary Tool is immensely powerful in summarizing large and/or complicated workflows.  However, some companies have begun to bar the use of certain GenAI applications, like ChatGPT. Unfortunately this makes the use of the Workflow Summary Tool impossible.  At the same time those companies are allowing the use of other forms of GenAI, like AzureAI.

In the Workflow Summary tool, it would be nice to have the capability to select which GenAI engine you want to use (ChatGPT, AzureAI, etc) so that you don't break corporate policy by using barred applications.  This could simply be a dropdown in the GUI configuration for the Workflow Summary Tool with a list of the most common engines.  The user would then supply their API key for that engine, and you're off to the races.

We are trying to utilize Alteryx Workflow migration workflow to setup proper SDLC environments and ensure we have less human intervention in the process. For example, if we create a gallery data connection XYZ in multiple Alteryx environments and try to run the migration workflow, the connection IDs are different in those environments regardless of how we name them. So even if we migrated the workflow, we still have to manually go to each environment, update the connection(s) and upload it again. That sort of defeats the purpose of migration concept itself.

Suggestion is to use gallery connection name/alias as connection ID so that when workflows migrated, connections are mapped accordingly. 

It would be great to dynamic update the next Analytic App based on an interface input. This mean I have a chained app. In Step 1 I ask a Yes/No Question. The Answer to this question will determine to open in Step 2 Analytic App A (with it's own interface Inputs) or Analytic App B (with other interface inputs).

Many users are facing this issue when they want to create an tool (e.g. for mapping purposes) that contains two datastreams/flows with different interface input requirements.

Adding this feature would allow us to create different dataflows with different input requirements. This helps us to differentiate between different mappingsschemes and increases userexperience (currently they have to fill a lot of unnecessary interface inputs). Thanks.

H.

With the onset of Workflow Comparisons in V2021.3, it only seems natural to me that the next step would be a method of handling those changes. Maybe have some clickable dropdowns on the changed tools that have a few options as to what you'd like to do about them. I think the options to start off with would be "Apply this change to that workflow" and "Apply the other workflow's change to this one" along with the "Apply all of this workflow's changes to that one" and "Apply all of that workflow's changes to this one" somewhere in the header.

I know that I will occasionally get a request to change a workflow while I'm already in the middle of making a change to it or am waiting on approval for a change I've made and am hoping to implement. The current version control system on Server does not make it easy to implement multiple changes that may need to be implemented in an order other than the one in which they were started. The current process seems to be to merge them later by going through the whole process of selectively copying the changed tools and pasting/replacing them or otherwise manually modifying the tools to make them match.

Likewise, implementing the version merging proposed here will allow versioning strategies more akin to branches in git. One could more-or-less maintain two streams of changes until they were both complete and merge or productionize them as they're complete and ready.