Alteryx Designer Desktop Ideas

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:

replace([#1],"$`","$C8:C8`")

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.

Solution

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.

The newest versions of Alteryx have the Designer Interface Calendar tool being very large when the app is run in Designer.  Anyway to give us the option to size it?  The old version was much more manageable from a development perspective when you have several of them on one screen.  Now you can barely fit 3 of them in one 23in screen.

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.

I suggest Alteryx may add a new interface tool / enhance existing date interface tool to allow selection of time period.

For the output of the interface tool, i believe we can simply concatenate the text (e.g. 111030AM) and perform transformation by other Alteryx tool.

The interface can be something like this, multiple drop down box which order in a single row.

Although there is workaround of creating 4 drop down box, but the presentation on Analytic app and gallery is not good (those text box is separated into multiple line.

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.

Recommendation:

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 

When building iterative macros and debugging I tend to copy an paste the calculation part multiple times underneath to see what the status would be on iteration 2, 3, 4... However when there are multiple inputs to tools in the calculation steps, for example join tools or unions, then for each step it need re-connecting. 

So the idea is two fold

1) Allow the user to 'lock' an input so that when that tool is copied the upstream connection point is always the same, e.g. the R input for the join tool is automatically connected to the D input macro whenever that tool is copied

2) For iteration outputs, recognise that the select tool is connected to an iteration input so when it is copied it takes the iteration output as the upstream tool.

for example, the default filename is

FileA_P10.xlsx the P10 mean the month. and i want to give a freedom to user to amend or change the filename.  

hence, i put the interface text box to show the default text built by formula, but it only able to input text only.

from this > "FileA_P10.xlsx"

to this   >   "FileA_P" + datetimeformat(datetimetoday,"%m") + ".xlsx"

and it is better if it apply for other interface tool.

It would be really useful to select a default date for Date interface tools for the end user. Really useful in other interface tools and would save a lot of time in testing.

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.

Hi team, Can I have dropdown for Action tool link to container?

a: Check to disable, uncheck to enable

b. Check to enable, uncheck to disable

it was very confuse for me when i want to do a reverse way. it is good to if it able to apply to other interface.

As a best practice, I label a Control Parameter with the exact field name that I want to map to in the workflow. This takes any guesswork out of maintenance down the road. I want the macro questions to automap the labels to field names, just like a Join tool automaps the right side to the left when a field name is chosen from the left side drop down.

It would be very helpful if we could pick from a list of installed calgary datasets in the dropdown menu:

we currently have the ability to choose geocoder/drivetime/Allocate datasets which are typically stored in the .ini files, but don't currently have the ability to choose calgary datasets. 

As a change to Designer UI in 2021.2, when in the filter box, I used to be able to use my mouse to click a little X in the corner to clear the filter or sort that had been implemented and it would immediately clear the filter.  It's not working as of 2021.2.  Now, I must navigate to the last cascade to get to the word Clear and click on it to clear the filter. 

This feels like another very tiny move in the wrong direction. These small UI changes cause 2 or 3 additional steps and slow the diagnostic/navigation process in moving around the Results Grid in the Browse Tool or at any point in the flow where the Results Grid is used.

Can the X in the top level of the Filter/Sort box in the Results Grid be restored in 2021.2?

Related to submission:

Small fix for the UI in the Results Grid (or Browse Tool)

Small Keyboard fix for the browse tool's filter

As a change to Designer UI in 2021.2, when in the filter box, I used to be able to use my mouse to Paste in the value and then hit enter/apply to apply the filter.  It's not working as of 2021.2.  Now, if I hit paste from my mouse, it just closes the Filter box and applies nothing.  It forces me to have to change between mouse and keyboard as that is the only way to paste a value into the filter value box (CTRL-V). 

This feels like another very tiny move in the wrong direction. These small UI changes cause 2 or 3 additional steps and slow the diagnostic/navigation process in moving around the Results Grid in the Browse Tool or at any point in the flow where the Results Grid is used.

Can mouse functionality be restored in 2021.2?

Related to submission: 

from  patrick_digan

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.

When outputting data to a spreadsheet, the default option is "output to a new sheet". The second time you run your process, you get an error unless you are amazing enough to remember to change the output option to "overwrite sheet".

If you change to "overwrite sheet" for the first run, it actually works just fine and creates the new sheet. 

Can Alteryx just eliminate the "output to a new sheet option" so that users will no longer be concerned that "Alteryx doesn't work" when they get this error after creating their first process? And the rest of us will be able to save the run time with an error, then the change of the option?

Thanks!

Looking for a way to make multi-selection much easier (rather than single click per item).  Could be an improvement on the List Box, or a new tool that allows multi-selection with highlighting desired items.  Control/Shift keys for selections similar to Windows, etc.

Most of the time I use containers to help structure and layout my workflow, as well as then enabling or disabling different parts of it. It would be nice however to still see the tools within a disabled container but have the container greyed out or hashed out?

Enabled Tool Container

Disabled Tool Container

Thanks,

Sam 🙂

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