Alteryx Designer Desktop Ideas

The JOIN tool could use some love.  Let's consider merging the JOIN and UNION functions into a single tool.  Instead of strictly L, J, and R outputs, we could have an option to allow for all standard SQL joins:

• Cross Join (Warning!!!)
• Inner Join (boring)
• Left Outer Join (saves time configuring Union)
• Right Outer Join (saves time ...)
• Full Outer Join (saves time ...)

Being able to JOIN on case-insensitive values is a big bonus (resisted urge to BOLD and change font size).

Being able to JOIN on date-range is often requested.

Being able to JOIN on numeric-range is often requested.

If we are combining tools, getting UNIQUE on L or R (or both) inputs would also save time.  Most JOIN errors are because the incoming (R) data contains duplicates by KEY.

cheers,

Mark

Hi @NicoleJ 

Currently the select tool can reorder data by sorting or selecting the field and then clicking the up or down button.  This is tedious when you have a data set with 400 fields.  I suggest you add a drag and drop functionality to the field list to facilitate reordering data.

A very useful and common function
https://www.w3schools.com/sql/func_sqlserver_coalesce.asp

Return the first non-null value in a list:

Curently the yxdb python library is not a pre installed library as per alteryx to allow python to read yxdb files. This should be done to make it easier to read yxdb tools within the python tool in Alteryx, or have a function built in the alteryx library to allow teh same functionality 

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

Currently when a unique tool is used, and a field is removed upstream then the workflow fails to move forward. If you have one or two unique fields being used then it is no big deal, but when you have a very complex workflow then you have to click into each one of those tools in order to update. This can be very problematic and creates a lot of time following all the branches that is connected after the 1st unique tool is used. My suggestion is to make this a warning instead of a fail or have an option to select fail or warning like the union tool is setup. This way people can decide how they want this tool to react when fields are removed. 

While Alteryx Designer's Input Tool will correctly presume that DateTime values from a SQL Server query are indeed DateTime types, it does not correctly presume that DATE type values should remain as Date types.  Instead, they are currently interpreted as Strings.  While downstream tools, such as Select, Formula, and DateTime can transform the types, this can impact run times.  I suggest that the Input Tool do correct interpretation of Date types in the origin data set.

There is no tool that exists that outputs all records that are duplicates (those sharing the selected values with at least one other record) and also outputs the records that are not duplicates (those not sharing the selected values with at least one other record).

The Unique Tool is not sufficient.  It only provides the first record of a unique duplicate group along with any non-duplicates and then provides a secondary output that only contains the additional records of a duplicate group.  Sometimes you only care about the duplicates and want to quickly see what differs between the unique groups.

For example, if there are 4 records with the City of Austin and I am looking for duplicates on City I want to see all 4 records with Austin in the output so I can quickly compare additional fields to see what might differ, or if they are all indeed truly duplicates.

Hello all,

I really appreciate the ability to test tools in the Laboratory category :

However, these nice tools should go out of laboratory and become supported after a few monhs/quarters. Right now, without Alteryx support, we cannot use it for production workflow.

Example given :
Visual Layout Tool introduced in 2017
https://community.alteryx.com/t5/Alteryx-Designer-Knowledge-Base/Tool-Mastery-Visual-Layout/ta-p/835...

Make columns Tool also introduced in 2017
https://community.alteryx.com/t5/Alteryx-Designer-Knowledge-Base/Make-Columns-Tool/ta-p/67108

Transpose In-DB in 10.6 introduced 2016
https://help.alteryx.com/10.6/LockInTranspose.htm

etc, etc...

Best regards,

Simon

Hi there

My idea is to have an option to copy and paste a tools configuration to a different tool of the same type somewhere else on the canvas.

Example:

Say I have four summarise tools dealing with four different data streams, I envision a 'Copy Tool Configuration' option after right clicking on a tool and then a 'Paste Tool Configuration" which can be applied across the multiple instances of the summarise tool by overwriting. This would preserve the tools anchors incoming and outgoing connections.

Benefit:

This would increase the speed of developing workflows. Naturally this would be significantly quicker than copy and pasting tools, and then re-wiring anchors. Additionally, this would potentially reduce human error when iteratively developing workflows.

Regards - Rhys Cooper

The idea behind encrypting or locking a workflow is good for users to maintain the workflow as designed. 

However, when a user reaches a level of maturity equivalent to that of the builder or more, or even when changes are required - the current practice is to keep a locked and unlocked version of the workflow so that it allows for a change in the future. 

It would be much simpler if we can have the power to lock and unlock workflows with a password. Users can then maintain and keep the passwords so that they can continue with the workflow. 

Not everybody is on Server yet so this feature is very helpful for control before Server migration. Otherwise it’s just password protecting a folder containing the workflow package, then re-locking a new save file each time a change is made or when someone new takes over on prem. 

Hello all,

When using in-database, all you have in select or formula are the Alteryx field types (V_String, etc..).

However, since you're mostly writing in database, in the end, there is a conversion of Alteryx field types to real SQL field types (like varchar). But how is it done ? As of today, it's a total black box. Some documentation would be appreciated.

Best regards,

Simon

Currently it's not possible to "switch off" interface tools in the same was as we can with the other tools. This limits the functionality especially within chained apps. If we could switch these tools off it would be much easier for us to tailor the experience by allowing selections to be activated by logic, rather than simply the data therein.

Please Alteryx Gods. I beseech thee!

*lights candles*

Hello,

As of today, there are only few packages that are embedded with Alteryx Python tool. However :
1/Python becomes more and more popular. We will use this tool intensively in the next years
2/Python is based on existing packages. This is the force of the language
3/On Alteryx, adding a package is not that easy : you need to have admin rights and if you want your colleagues to open your workflow, it also means that he has to install it himself. In corporate environments, it means loosing time, several days on a project.

Personnaly, I would Polars, DuckDB.. that are way faster than Panda.

Hello,

There are several dozens of data sources... maybe it would be useful to have a search in it?

Best regards,

Simon

Connecting to Smartsheets using Alteryx Desktop (and by extension, Alteryx Server) is extremely cumbersome. If a user wants to read data from Smartsheet, they are required to get an API token (preferred) or use a username/password

Then do one of the following to read data from Smartsheets:

1. a. Install a ODBC driver

    b. Configure a DSN connection for ODBC
    c. Use the input data using a generic ODBC connection
or
2. Use python

To write data to Smartsheets, a user can use Python or upload the data using an API call - both very hard for end users to use especially if they're not Python developers.

Regardless, all of these are problematic. On the server I manage, I have over 15 ODBC connections to Smartsheets and it's getting very hard to upgrade the server hardware because of them. Creating a native connector for input/output of data to Smartsheets will eliminate a headache of managing ODBC connections, and make it simple for Alteryx Desktop users to read and write data.

Adding a up and down arrow on each column would make it easier and quicker to sort columns then the drop down menu or sort tool

Search Box for Tools like Formula Tool where a drop down list of all columns is present to choose from the list. It might take quite a while to search for a specific column in a Formula tool when there is hundreds of columns in a data stream. This is quite an important case when we work with raw columns directly from an SAP extractor.