Calling all Racers for the Alteryx Grand Prix! It's time to rev your engines and race to the stage at Inspire! Sign up here.

Alteryx Designer Ideas

Share your Designer 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:




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:

Alteryx Choreographer.png


I'm looking forward to hear what you think.


11 - Bolide

This is truly some big brain stuff @Aguisande , thank you.


Sheesh, conditional execution is so important and I find it so amazingly frustrating that I cannot do something so simple as not have a bunch of tools execute if a particular data condition is met.  Yes, you can create a match macro and hustle your way into it, but the considering the state of macro governance within server and gallery, this is not a very good solution.  I know that in my old coding days, it was pretty much the simplest thing ever:


if (condition) then 

  do a bunch of stuff

end if


The fact that I can do amazing aggregations and analysis that would take me weeks to code, but can't have the engine completely ignore components based on a simple yes/no filter without resorting to conditionally disabled containers continues to amaze me.  

8 - Asteroid

Fantastic idea

8 - Asteroid

Fantastic Idea and brilliant write up.

5 - Atom

I love the write up and idea.  I was actually about to suggest an orchestration idea and saw this, and I will simply add my 2 cents to a fantastic suggestion.   I would add the idea that we have a new type of workflow versus tools.  The pure speed of the parallel just work as fast as you can in the current tool is amazing and I would hate to impact current performance.  However, if we had an orchestration workflow that enabled the ideas here, I could completely get on board with that.


And again, fantastic presentation and idea

12 - Quasar
12 - Quasar



Thanks a lot for putting this together. I think this would be very useful from a scaling and modular way of developing.

Alteryx Community Team
Alteryx Community Team
Status changed to: Revisit

Hi All!


Thank you for your feedback and enthusiasm for this idea! We appreciate seeing so much engagement on an idea.


Our product team has reviewed this, and we're unable to include this on the near future road map, which is why I'm placing this idea in this status. However, we are currently working on research and scoping for our roadmap beyond the near future releases and our product team would like to consider each of the ideas represented in this request as separate feature suggestions for those releases. This way we can assess and prioritize those items to the best of our ability while taking into account our existing roadmap updates and the information discovered during that research.


We'll do our best to update this idea in the future once we have more information on the status of this idea in it's components and as a whole.

17 - Castor
17 - Castor

This would be a game-changer @Aguisande 

12 - Quasar

I like this idea and think the Tool Container's capabilities should be extended. The one thing that I would add is it would be great to be able to execute a self-contained workflow in such a container, so that you can chain workflows in such a view. This is essentially what the Crew Macros do today with the runner & conditional runner, log parsers etc.

6 - Meteoroid

As others have said - great write up, as a relatively new customer to Alteryx it seems almost inexplicable that there isn't a simple way of getting Alteryx to run in a specific order.  It is incredibly frustrating and irritating


A shame it can't be included in the near future road map - seems such basic functionality (although of course easier to implement an idea than in practice)


@Aguisandethank you so much for putting this out there. I remember when you presented it awhile back and the pain points you brought up with trying to use Alteryx to simply specify order, conditionally execute, etc... It's a very thorough approach to these common issues and has been valuable internally thus far!


Thanks again!