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

Featured Ideas

Hello all,

As of today, you can populate the Drop Down tool in the interface category with a query launched from a in-memory connection. I would really appreciate the ability to use instead an in-db connection.



Why ?
It means managing two connections instead of one, and finding ways to manage it on server for both of them, etc etc.. Simplicity is key.

Best regards,


Right now, the List Box interface tool allows end users to select multiple options of fields for selections, filtering, and formatting/formulating. 


However, it doesn't do quite as good when a use case has over 1,000+ columns/fields. This is made even more complicated with each column/field having somewhat similar naming conventions thereby causing confusion. 


Having a search function, as made available in standard Select Tools, Join tools, and other tools that has filtering capacity, will be most helpful for developers to give maximum flexibility to end users.

I have developed many workflows, macros, and apps, and I have always had to find a workaround for displaying information on the user config page or user interface.


For example, I want to input 'Default text' into the Text Box interface tool, but the problem is that it does not accept any external connection.

It would be great if this tool had a Q input anchor that could accept data from a connected tool (in both single or multi-line mode) or from external input (such as a file for DropDown list or List Box tools).



TextBox_with Default_text.PNG


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.


Alteryx gods,


It would make me even happier than I am now if it were possible to tailor the completion messaging in the Interface Designer when an analytic app completes.

Currently, we use rendering etc, but sometimes we simply want to be able to create a bespoke completion message.

My example is as follows:

In the app you have the option to download files, or have them emailed to you. If you choose download, the final display is the render tool with the documents listed, however, if you choose email I want nothing to show but the final window with the message "Please check your email" or something. There may be more than one option, and so being able to dynamically change these messages would be very useful.


Help me Alteryx gods, you're my only hope.


*beep boop boop*

When searching for a workflow in the application we severely struggle with being able to locate the workflows we need. The same thing happens when searching in the gallery.  The information entered that will pull up a workflow doesn't seem to search across the workflow name nor does it seem to use any regular search engine function e.g. "search term" will return all and only results that contain exactly those parameters.  


WF Name:  "Magic_Workflow_business_purpose"

We can search for

  • Magic
  • Workflow
  • business
  • purpose
  • Magic_Workflow_business_purpose

For THIS particular workflow, let's say only the search term of "business" works. 


It seems to be completely inconsistent. We've had MANY circumstances where NO entered search parameters return the desired results and we find ourselves having to sort all workflows by name and slowly scroll through (waiting for more to load) until we locate the named workflow. Out of all the amazing things Alteryx can do, if we can't find the work we've developed in it, we can't use it.


Thank you!  


Regards, MAKpfe

Please add either or both

  1. "CustomFile/Database", similar to the TREE tool to the Text Box interface tool
  2. An option to make TREE Tool "silent" or passive when using the "CustomFile/Database" option

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,

  1. run all Interface tools first and modify config of other tools
  2. then run the rest of the tools on the canvas

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.

I think I'm liking the new UI, but I think it's necessary to bring back save, undo and re-do buttons....


1. Frequent saving of workflows is crucial and not everyone uses keyboard shortcuts

2. The ability to undo (lots) of changes is a key part of iterating and rapidly building workflows in Alteryx and again not everyone uses keyboard shortcuts to do this.


Looks like there's potentially space to add this to the right of 'help' (I suspect this might be technically quiet difficult) or to the left of 'run', 'schedule' and 'active documents' as seen in the image below.


Out of interest, where has the 'documents' terminology come from?


2018-11-14 22_12_14-Alteryx Designer x64 - PureGym Log In.yxmd_.png




Changing the Macro Input tool in an existing macro is dangerous and can result in unmapped fields or lost connections in workflows using the macro. For example, we have a widely used macro for which we'd like to change the name of an input field, change it's default type from Date to DateTime, make it optional while keeping other fields mandatory. Currently, we cannot find a solution which would not require us to fix each workflow using the macro after changing it. We should be able to change the field names, field types (e.g. String to V_WString, Date to DateTime), select optional fields and do other modifications to Macro Input without having to update each workflow using the macro. The new Macro Input UI could be enhanced with a window similar to that of Select tool's. Technically, the Macro Input fields could have a unique ID by which they would be recognised in workflows, so the field names would just be aliases that could be changed without losing the mapping. In summary, we are restricted to our initial setup of Macro Input and it is very complicated to change it afterwards, especially if the macro is used widely.

When writing a good amount of code, it is easy to get lost in a sea of parentheses.  Just when you think you're all done, you get an error that can force you to scour through your code to find the missing, extra, or misplaced parenthesis. 


A common feature today is to highlight a parenthesis when its partner is clicked on.  This instantly lets you know if you have the wrong number of them and where. 


I didn't think this was that important early on in Alteryx, at least for me.  Formulas were meant to be short and easily readable at a glance.  Now as I dig deeper, there's R, Python, SQL and other text-heavy inputs. 


I don't need a full-fledged text editor in Alteryx, but I would love some quality of life features like parentheses matching.

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:

  <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>


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.






It would be nice if we can arrange some tools on the canvas neatly by one click and having them distributed evenly (horizontally/vertically).


See this picture which worth thousand words.


Dsitribute Tools Horizontally/Vertically.jpg

When building out Alteryx workflows there may be a need to read in different ranges within the same Excel spreadsheet. For example bringing in a table from Sheet1, but also isolating a table name in a particular cell (in my example cell C8).




When turning this into an analytic app, with a file browse is to add an action tool with the default value of "Update Input Data Tool".



However when specifying this option within the analytic app interface, you are only allowed to chose one option of the following:

i) Select a sheet

ii) Select a sheet and specify a range

iii) a named range or

iv) a list of sheet names.


The problem is in the example above I need a sheet and a range, but I want to avoid adding two file browse interface tools as it shouldn't be needed. If the user selects (i) then it loses the reference to cell C8, but I would imagine a lot of users as they get started with apps don't realise this is what will happen.


There is however a way to solve this currently and it requires overwriting the default behaviour and configuring the second action tool (the one that updates the file for C8), to update value with a formula, where you assume the user would select sheet name and then use this formula:




However I would argue that this has a lot of technical debt, plus if the user needs to modify where the header is, for example to D8 they need to change the input file and the action tool so it works as a workflow and an analytic app.



Like how the configuration options for the input file, such as which row to input data from or whether first row contains data is maintained, modify the behaviour of the default option in the action tool to maintain references to ranges.



I will start off with a story. I have built a process to manage batch API requests. It's an iterative process that checks to see where the export is at by calling an API and then returning some status. It will run and wait and run and wait until the export is ready to be downloaded. However sometimes, the jobs don't finish and a status returns something like "failed" or "cancelled". When this is the case, I have my process (which is a little bit batch macro) kicks off an error message, using the nifty error message tool. After some time I noticed that it was a PAIN to go back and figure out which of my requests failed and I decided that I need to add some messaging around where this was failing, so I could do some easy auditing. So I go back into my tool and much to my chagrin, I cannot pass variables into the message section. I would expect it to have worked something like this:


"Record "+[#2]+" is not 'A'"


Can we please get a change to this. It would save a lot of time and energy if we could create a dynamic error message option.


TL;DR Please allow us to use formulas in the "If expression is true, display error message:" settings area.


I'm not finding it anywhere as a current option, but my company uses branded PowerPoint slides using our logo, these slides are in 16.:9 (widescreen) for slide size, but Alteryx won't output to that size even if I choose custom for page size & have Widescreen selected as an option. Could there be an Advanced Options button added that would allow users more output choices, like choosing the 16:9 ratio size output? Without it, I'm having to output the largest map I can create (13 x 9.75 in Report Map tool) and then stretch/shrink to get it to fit the 16:9 slide...for every single map/slide (currently making 40 maps at once).


Is there a work around to accomplish my goal currently? And if not, could the option be added to the Render tool? Thank you!

The drop down\list box have numerous ways to list values. One of them that I like is connecting to an external source. You simply have an external source file with a Name column and a Value column. It will display the data in the Name column and pass the data in the Value column. Now suppose instead of connecting to an external source I wanted to use connected tools. Currently, I would have to crosstab this data and the drop down\list box would display and pass the column names.


What if the drop down\list box could have an additional option added where you could connect tools and it would act identically as an external source (display the data in the Name column and pass the data in the Value column). This would be much easier and more functional!

This request is super simple!  I love how Alteryx displays the row count and size of the data passing through each tool at run time.  Can you set the default formatting for the row count indicators to be #,###?  Without the commas, it's hard to easily check the row count once you get more than 6-9 digits.


In the example below, it would be so much more readable if it displayed as 75,640,320.



There needs to be a way to step into macro a which is component of parent workflow for debugging.


Currently the only way to achieve to debug these is to capture the inputs to the macro from the parent workflow, and then run the amend inputs on the macro. For iterative / batch macros, there is no option to debug at all. This can be tedious, especially if there are a number of inputs, large amounts of data, or you are have nested macros.


There should be an option on the tool representing the macro in the parent workflow to trigger a Debug when running the workflow, this would result in the same behavior when choosing 'Debug' from the interface panel in the macro itself: a new 'debug' workflow is created with the inputs received from the parent workflow.


On iterative / batch macros, which iteration / control parameter value the debug will be triggered on should be required. So if a macro returns an error on the 3 iteration, then the user ticks 'Debug' and Iteration = 3. If it doesn't reach the 3rd iteration, then no debug workflow is created.

There are many circumstances when you have to build an interative macro where it's not just the iterating data set that needs to change every iteration, but also a second data set.

Think about this like a loop where two different variables are updated on every iteration, not just the control variable in the For xxx control variable.


The way that users work around this is to use a temporary yxdb file where instead of a macro input you input from the yxdb, and then write back to the same yxdb.    This allows you to pretend that you can adjust 2 different data sets on every cycle of the loop.    there are 4 downsides to this:
a) User complexity - this breaks the conceptual simplicity of macro inputs since now the users have to understand that in situation X I use macro inputs; and in situation Y I have to use some other type of tool.

b) Speed penalty - writing to disk is between 1000x slower and 1 000 000x slower than working with data in memory (especially if it's in cache) - so by forcing this to go through a yxdb file, you do incur a speed penalty which is just not needed

c) blocking penalty - Because of the fact that you can't write to a file that you're still reading from, you need to pepper this with Block until done tools - and you need to initialize the macro using a first write to the yxdb file outside the macro - which further hurts speed.    Given the nuanced behaviour of block-until-done, this also introduces user complexity issues

d) Self-contained - because you have to initialize these files outside the macro - the macro is no-longer self-contained and portable (which breaks the principle of Information Hiding which is a key pillar of good modular decoupled software design.


The other way that users work around this - is to serialize their entire second recordset into a field which then gets tacked onto the iterating data set using an iterative macro.   This is HIGHLY wasteful becuase then you have to build a serialize & deserialize process for this second recordset.    It fixes the speed and blocking penalites from above, but introduces a computational overhead which is generating no value; and makes this even more complex for users - and a further blocker to using macros.




We could make this simpler by allowing users to create multiple pairs of macro input / macro outputs so that 2 or 3 or n different data sets can be updated with every iteration.



Below is a screenshot demonstrating this, from an Advent of code challenge - the details of the problem are not important - the issue at hand is that there are 2 record sets which both need to be updated on every iteration.


cc: @NicoleJohnson @Samanthaj_hughes @SteveA 




I am running into unexpected functionality when utilizing the date interface tool in an Analytic App after upgrading to 21.3. Previously I was able to easily select dates in the past in the app interface by first selecting the Year, then the month, date, etc. After updating I am only able to see the prior and upcoming three months, which makes it difficult if you need to navigate back, say, 10 years. A ticket was put in they could not find when or why this change was made. This issue was brought up to our Designer SME group and they agreed that this isn't an improvement on the old design and is more cumbersome. They recommended posting to the Ideas page to bring back the old design.

Top Liked Authors