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

Featured Ideas

Allow users the ability to add a delay on the connection between Control Container tools. I frequently have to rerun workflows that use the control container because the workflow has not registered that the file was properly closed on outputting from one output tool to the next. The network drives haven't resolved and show that the file is still open while its moved on to the next control container. Users should have an option in the Configuration screen to add a delay before a signal is sent for the next container to run. 

 

In the past I was able to use a CReW tool (Wait a Second) in conjunction with the Block Until Done tool to add the delay in manually. But I have since converted all of my workflows over to Control Containers. Since then half of the times the workflow has run I encounter the following errors.

 

image.png

image.png

In the dynamic input tool,

Where you “Read a List of Data Sources”, there should be a radio button below the “Action” field, to   

 

“INCLUDE FIELD OF DATA SOURCES”,

 

Then you’d have an output field with the isolated name from which the data was sourced. You wouldn't be required to "include full file path" then parse out the sheet the data came from. 

Sometimes, Control Containers produce error messages even if they are deactivated by feeding an empty table into their input connection.

 

screenshot_error_in_spite_control_container_deactivated.png

(Note that this is a made up example of something which can happen if input tables might be from different sources and have different columns so that they need separated treatment.)

 

According to the product team, this is expected behaviour since a selection does not allow zero columns selected. This might be true (which I doubt a bit), but it is at least counter-intuitive. If this behaviour cannot be avoided in total, I have a proposal which would improve the user experience without changing the entire workflow validation logic.

(The support engineer understands the point and has raised a defect.)

 

Instead of writing messages inside Control Containers directly to the log output (on screen, in logfile) and to mark the workflow as erroneous, I propose to introduce a message (message, warning, error) stack for tools inside Control Containers:

  1. When the configuration validation is executed:
    1. Messages (messages, warnings, errors) produced outside of Control Containers are output to the screen log and to the log files (as today).
    2. Messages (messages, warning, errors) produced inside of Control Containers are not yet output but stored in a message stack.
  2. At the moment when it is decided whether a Control container is activated or deactivated:
    1. If Control Container activated: Write the previously stored message stack for this Control Container to the screen and to the log output, and increase error and warning counts accordingly.
    2. If Control Container deactivated: Delete the message stack for this Control Container (w/o reporting anything to the log and w/o increasing error and warning count).

This would result in a different sequence of messages than today (because everything inside activated Control Containers would be reported later than today). Since there’s no logical order of messages anyways, this would not matter. And it would avoid the apparently illogical case that deactivated Control Containers produce errors.

I would really love to have a tool "Dynamic change type" or "Dynamic re-type" which is used just as "Dynamic Rename".

 

  • "Take Type from First Row of Data": By definition, all columns are of a string type initially. Sets the type of the column according to the string in the first row of data.
    Col 1Col 2Col 3Col 4
    DoubleInt32V_StringDate
    123.45617Hello2023-10-30
    3.4e17123Bye2024-01-01
  • "Take Type from Right Input Metadata": Changes the types of the left input table to the ones by right input.
  • "Take Type from Right Input Rows": Changes the types based on a table with columns "Name" and "New Type".
    NameNew Type
    Col 1Double
    Col 2Int32
    Col 3V_String
    Col 4Date

It would be nice to have a visual cue for a detour tool's configuration. This is especially the case when testing with several detour tools in a workflow - see the cleanse.yxmc screenshot below. I added an annotation to one of the detour tools as a possible solution.

 

Any of these options that would save the additional click would be appreciated.

  • Default annotation shows "Detour left" or "Detour right"
  • Detour outgoing wire highlighted (mentioned in Detour dashing)
  • Detour direction outgoing anchor that is NOT used is grayed out
  • Detour direction outgoing wire that in NOT used is grayed out
  • Detour tool has a left/right toggle
  • Detour tool changes color when set to detour right

Personally, I prefer that the outgoing anchor and outgoing wire not in use be grayed out. But even the default annotation stating the direction would be helpful.

 

Does anyone else have a preference or other ideas on the visual cues?

 

Detour in cleanse tool.png

Hi there,

 

When creating a database connection - Alteryx's default behaviour is to create an ODBC DSN-linked connection.

 

However DSN-linked connections do not work on a large server env - because this would require administrators to create these DSNs on every worker node and on every disaster recovery node, and update them all every time a canvas changes.

they are also not fully safe becuase part of the configuration of your canvas is held in the DSN - and so you cannot just rely on the code that's under version control.

 

So:

Could we add a feature to Alteryx Designer that allows a user to expand a DSN into a fully-declared conneciton string?

In other words - if the connection string is listed as 

- odbc:DSN=DSNSnowFlakeTest;UID=Username;PWD=__EncPwd1__|||NEWTESTDB.PUBLIC.MYTESTTABLE

Then offer the user the ability to expand this out by interrogating the ODBC Connection manager to instead have the fully described connection string like this:
odbc:DRIVER={SnowflakeDSIIDriver};UID=Username;pwd=__EncPwd1__;authenticator=Snowflake;WAREHOUSE=compute_wh;SERVER=xnb27844.us-east-1.snowflakecomputing.com;SCHEMA=PUBLIC;DATABASE=NewTestDB;Staging=local;Method=user

 

NOTE: This is exactly what users need to do manually today anyway to get to a DSN-less conneciton string - they have to craete a file DSN to figure out all the attributes (by opening it up in Notepad) and then paste these into the connection string manually.

 

Thanks all 

Sean

 

 

0 Likes

Hi all,

 

Hope you are doing well! Recently I have come across a use case where I had to dynamically rename columns based on Field name ánd position. While I was able to come to a solution using a set of tools, it got me thinking: would it be possible to include the Fieldnumber function exactly like already has been done in the dynamic select tool (i.e. 'Select via a Formula - Column Position' example)?

 

For example, one would write: IF ([FieldNumber] = 1) OR ([FieldNumber] = 3) OR ([FieldNumber] = 7) THEN [_CurrentField_]+"_Code" ELSE  [_CurrentField_] ENDIF

 

 

0 Likes

Currently, Control Containers only report in case they are activated:

Info: Control Container (3): Control Container Activated.
...
Info: Control Container (3): Control Container Completed.

It would be very helpful to also get information on disabled Control Containers:

Info: Control Container (3): Control Container Deactivated.
0 Likes

In many programming languages, errors can be thrown and caught so that the final program does not fail even if a procedure or function produces an error.

 

I would like to propose something similar for Alteryx, using the Control Containers. Already now, a Control Container outputs the log in the container to its output stream on the upper right corner:

control_container_log-02.png 

Still, the workflow produces an error:

control_container_log-01.png

My idea is to optionally avoid the error output to the log but only report the error through the control container's output log. The error message in the output log should be "degraded" to a warning. The output log of the control container should stay unchanged. The configuration of the Control Container could look like this (addition in red):

control_container_configuration-01.png

This would help a lot if stuff produced by others is used (e.g., third party macros) which might fail while this might be normal behaviour for the workflow.

Top Liked Authors