Community Spring Cleaning week is here! Join your fellow Maveryx in digging through your old posts and marking comments on them as solved. Learn more here!
The Product Idea boards have gotten an update to better integrate them within our Product team's idea cycle! However this update does have a few unique behaviors, if you have any questions about them check out our FAQ.

Alteryx Designer Desktop Ideas

Share your Designer Desktop product ideas - we're listening!
Submitting an Idea?

Be sure to review our Idea Submission Guidelines for more information!

Submission Guidelines

Design Patterns, Order of execution, Conditional execution & Orchestration

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:

OnCanvas.png

 

 

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:

 

ToolcontainerConfig_Comment.png

 

 
  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:

Alteryx Choreographer.png

 

I'm looking forward to hear what you think.

Best

36 Comments
Aguisande
15 - Aurora
15 - Aurora

Thanks @JeffA 

As you know, I not only love Alteryx, but always want to make it better!

I´m very glad that there are people actually reading this.

Thanks again

CristonS
Alteryx Alumni (Retired)
Status changed to: Under Review

The Product team is researching how to allow users to order and control the execution of the tools in a workflow. This will be a coordinated effort between UX, Engine, and Designer teams. No ETA, but we'll update this idea if or when it makes it to the roadmap.

 

hroderick-thr
11 - Bolide

There are several good ideas bundled together here. If some could be delivered sooner separately, please do.

jrobiso2
8 - Asteroid

Brilliant!  I need to have a step in my master workflow that says "If today is Friday, also do this other section of workflow. Any other day? Skip it".  Currently I don't think there is a way to do that, at least not easily.

 

Your ideas would make it pretty simple, I would think.

hroderick-thr
11 - Bolide

I saw a Designer roadmap presentation recently and a feature expected next year is to give Containers some process control options.

I truly am looking forward to that and hoping it works really well

Thableaus
17 - Castor
17 - Castor

There has been a year and nothing coming through yet. Feel a bit disappointed.

CristonS
Alteryx Alumni (Retired)

hi @Thableaus there is a LOT going on in this awesome post, and it was only placed under review in May 2021 : ) There are components here that we want on the roadmap, and some that already are on the roadmap, and some that we're not going to do. When we have a clearer picture, I will update this post. Thank you for your continued engagement!

SeanAdams
17 - Castor
17 - Castor

@Aguisande 

This is still one of the most well-articulated and fully realised ideas on the community AJ - and I fully agree on the need for flow of control and conditional execution.

 

The easiest example is when you load data into dependant tables (this needs to go in order) or if you need to call an API only if you get results from a file process - this is super essential!

JohnPelletier
Alteryx Alumni (Retired)

Thanks for the ideas, @Aguisande. From what I can understand this is addressing a need for orchestration within a workflow of the containers and how to tailor the operation order for them. Is that accurate? 

Do you also require orchestration of the sequence of workflows with other workflows? We have some ideas on that but would rather stick to requirements for the discussion at hand:

1.  The orchestrator must not use up a spot on the controller queue while controlling the flow of execution of other workflows.

2. The analyst should be able to construct the flow simply and see a graphical representation of it to understand it.

3. Outputs from some workflows should be able to be inputs for other workflows

4. When a workflow starts/reaches a milestone/finishes, it should be able to trigger the next workflow(s) to start.  

5. Must be able to launch a Server workflow from an Alteryx or 3rd-party application, and to be able to launch an Alteryx or 3rd-party application from Server when starting the next step in the sequence. 

 

Do these sound right? How would any of you prioritize them? Are there more to add? Are some not needed? Feedback is greatly appreciated.

hroderick-thr
11 - Bolide

Thanks for taking a hard look @JohnPelletier . Here are my priorities

 

1.  The orchestrator must not use up a spot on the controller queue while controlling the flow of execution of other workflows.

ZERO PRIORITY

2. The analyst should be able to construct the flow simply and see a graphical representation of it to understand it.

THIRD PRIORITY, BUT PRETTY IMPORTANT

3. Outputs from some workflows should be able to be inputs for other workflows

SECOND PRIORITY, PLUS OUTPUT CONNECTORS ON OUTPUT TOOL TO MAKE OUTPUT TOOK A MILESTONE INSTEAD OF AN END POINT

4. When a workflow starts/reaches a milestone/finishes, it should be able to trigger the next workflow(s) to start. 

FIRST PRIORITY, PLUS BE ABLE TO RETURN TO CONTINUE WITH TOOLS THAT FOLLOW MILESTONE IN THE ORCHESTRATOR

5. Must be able to launch a Server workflow from an Alteryx or 3rd-party application, and to be able to launch an Alteryx or 3rd-party application from Server when starting the next step in the sequence. 

ZERO PRIORITY