Alteryx Designer Desktop Ideas

The Source field of the field metadata is very useful, but has some problems.

• It is repetitious. A long connection string repeated for many fields from the same source can bloat the size of the workflow above 10 MB, and when removed is around 0.5 MB.
• It exposes sensitive information about a company's infrastructure, such as server names, ports, user ids, and proprietary data structures.

I first started paying attention when we found a user's password in the metadata because they had passed it as a string to the Dynamic Input Tool (separate Idea submitted for that - LINK). Then when I had to share an App with the Alteryx Support team for support with an issue, I thought to check the metadata, and I noticed that the file was too big and was exposing information that I would not normally share with another company.

I'm not sure how you want to handle this, but here's some thoughts:

• Default the Source field to 'off' and provide users the option to turn it 'on' in the workflow/app settings.
• Provide a mechanism to strip the 'Source' field at time of saving or exporting the workflow.
• If nothing else, provide education to users on the implications of including this information in the file.

Thanks for listening!

Cameron

Hi there,

We often get the following error message from the download tool 

"00:00:23.555 - Error - ToolId 106: Error in libCURL: You have found a bug.  Replicate, then let us know.  We shall fix it soon."

Unfortunately this seems to be a transient error so we've not been able to replicate this in a useful & repeatable way.  However - we see this happening at least a few times per week on one of our servers, so this is a continuing issue.

Please could you provide more detailed error messaging on the download tool so that this error can be debugged and/or replicated?

Many thanks

Sean

TIBCO Data Virtualization is a Data Virtualization product focused on creating a virtual data store consolidating data from throughout the enterprise.  It can be accessed via a SQL query engine, and has a variety of supported connectors, including an ODBC driver.

This data source can be connected to via ODBC in Alteryx today, but error messaging is unclear/unhelpful, and attempting to use the Visual Query Builder causes Alteryx to crash.

Adding TIBCO Data Virtualization as a supported ODBC connection would empower business users to leverage this product and easily utilize this enterprise data store, enhancing the value of the Alteryx platform as a consumer of this data.

Idea:

I know cache-related ideas have already been posted (cache macros; cache tools), but I would like it if cache were simply built into every tool, similar to the way it is on the Input Tool.

Reasoning:

During workflow development, I'll run the workflow repeatedly, and especially if there is sizeable data or an R tool involved, it can get really time consuming.

Implementation ideas:

I can see where managing cache could be tricky: in a large workflow processing a lot of data, nobody would want to maintain dozens of copies of that data.  But there may be ways of just monitoring changes to the workflow in order to know if something needs to be rebuilt or not: e.g. suppose I cache a Predictive Tool, and then make no changes to any tool preceeding it in the workflow... the next time I run, the engine should be able to look at "cache flags" and/or "modified tool flags" to determine where it should start: basically start at the "furthest along cache" that has no "modified tools" preceeding it.

Anyway, just a thought.

Bring back the Cache checkbox for Input tools. It's cool that we can cache individual tools in 2018.4. 

The catch is that for every cache point I have to run the entire workflow. With large workflows that can take a considerable amount of time and hinders development. Because I have to run the workflow over and over just to cache all my data.

Add the cache checkbox back for input tools to make the software more user friendly.

The new Interactive Chart is a great tool that I've been using. A big improvement to it would be to allow a secondary axis, as well as allowing data points to show on the chart. I have attached a sample chart that was created in Excel. 

In order to perform audit-trail logging - it would be valuable to have 2 new capabilities

a) environment variables which show the workflow name; filepath; version; run start date and time; etc.   For any worklows we build, we need to have a solid audit trail to be SOX compliant, so having this detail available as a data field to write and manipulate is essential

b) A logging component.   What would be great is a component that you can drop on a workflow, not connected to anything, which is able to trap the start; end; runtime; version; etc of a workflow; and commit this to any output data format (CSV or ODBC etc).   This logging tool would need to be able to capture the full runtime, so it would need to be the last thing that runs (which means it may need to exist in parallel to the main workflow in some way).    This is not currently possible with a complex workflow with outputs, because it's not possible to identify when the entire workflow ended; or the runtime (since output tools don't have an onward connector to pass flow-of-control to catch the final end-time)

Again, both of these are necessary to meet audit requirements for workflows and prodcution-quality ETLs for BI data warehouses.

When the append tool detects no records in the source, it throws a warning. I would like to have the ability to supress this warning. In general, all tools should have similar warning/error controls.

It would be great if you could create default settings for the Tool Containers. As workflows become larger, I use containers a lot. But once I have 10-15 containers, I have to set all of them to have a Transparency of 1 and a margin of None. While the changes don't take long to make, it would be nice if they could be preset.

I've seen several posts and questions concerning NULL dates.  Is 09/31/2010 a valid date?  I know that 02/29/206 isn't valid and that 02/00/2006 isn't either, but I really don't like finding out about these in conversion warning messages.

I might suggest a function that returns True or False on the date check and let the user configure appropriate rules to rethink the attempted date prior to committing the field to the date data type.

Cheers,

Mark

Hello .. me again!

Please can you fix the copy and paste of renames across field.  It's a behavior that I see in many tool's grids and drives me mad.  Its not just select. 

Take the attached screen shot.  In the select tool, i've renamed "test 2" to "rename2".  Fine it works. No issue.

I then copy rename2 and paste into the test3 field, and it copys the entire row's data (and metadata) into that little box, tabs, spaces the lot.  I end up with something like the screenshot.  Really not sure it was meant to be designed this way, as I cant really see the point.

Please can you fix this bug

Jay

Alteryx should raise a Conversion Error if re-sizing of a string field in a Select tool results in data truncation. It does this for integers but if a string is truncated there is no indication of this in the workflow output.

API Security requirements are constantly evolving and strengthening.  As API architectures migrate from traditional authentication models (Basic, OAuth, etc.) to more secure, certificate-based models, like MTLS/MSSL, leveraging Alteryx Designer will become increasingly difficult, especially for larger organizations trying to scale the use of Alteryx across a large user base, with vastly diverse skillsets.

I realize issuing API calls with certificates is possible via the Run Command tool.  We consider this a temporary workaround, and not a permanent, strategic solution.  The Run Command tool can be clunky to use when passing in variables and passing the output back into the workflow for downstream processing.

Therefore, I would like to request a more scalable approach to issuing MTLS/MSSL API calls.  Can an option be added to the Download Tool to allow for certificates to be passed on API calls?

The email tool, such a great tool!  And such a minefield.  Both of the problems below could and maybe should be remedied on the SMTP side, but that's applying a pretty broad brush for a budding Alteryx community at a big company.  Read on!

"NOOOOOOOOOOOOOOOOOOO!"

What I said the first time I ran the email tool without testing it first.

1. Can I get a thumbs up if you ever connected a datasource directly to an email tool thinking "this is how I attach my data to the email" and instead sent hundreds... or millions of emails?  Oops.  Alteryx, what if you put an expected limit as is done with the append tool.  "Warn or Error if sending more than "n" emails."  (super cool if it could detect more than "n" emails to the same address, but not holding my breath).

2. make spoofing harder, super useful but... well my company frowns on this kind of thing.

Sometimes I want to test portions of a workflow, independent of other portions.  I find myself adding containers, just so I can disable some of the time consuming portions that are not part of my test.  It would be nice to be able to enable/disable any portion of a workflow, on the fly.  Or maybe just disable/enable any connection with a right-click.

Thanks!

Gary

In the Formula Tool, there is an Average() function which can be used to take the average/mean of multiple columns or expressions. This function treats null values as zeroes. This was a surprise/dissapointment to me as I am used to other applications & systems where nulls are ignored, for example Excel. It would be useful to have either an AverageIgnoreNulls() function or an optional extra parameter to Average() which specifies that nulls should be ignored rather than treated as zeroes.

When wishing to average a small number of columns and ignore nulls, a formula can be constructed using Iif(IsNull([Column1]),0,[Column1]) for each column to calculate the total, and Iif(IsNull([Column1]),0,1) for calculating the count. This quickly becomes unwieldy for more than 2 or 3 columns.

As an admin - we currently need to download a large number of different binaries for every release; then package them for internal deployment; then send them out.

This creates unnecessary work for our admin teams, our packaging teams, our deployment teams etc.

This problem is becoming more acute now that Alteryx is shipping add-on tools via the public gallery - so our standard desktop designer can now require 10 or more separately packaged installs.

Can we please change the download experience to allow enterprise admins to:

- Select the components that they want in a standard download

     - This would allow for a menu selection across all the starter kits (e.g. Tableau; microsoft; qlik); the standard designer; the predictive

     - it would also allow for a menu selection across public gallery assets so that we can include things like the model comparison tool and other new predictive capabilities

     - the addins for Microsoft R Server

     - database drivers

     - Connect data loaders

     - Server components

- Given this set a name (like "Standard designer install") since in a large enterprise we will have several different configurations (some for super-users; some for standard users).    In our world we'd have "Standard Designer"; "Admin"; "Connect Controller"; "SuperUser" as our starting list.

- Then download one installer which is the aggregated set of these in one place 

- ... and finally allow the Admin to be notified when any component in the install set changes so that they can download the new version.

cc: @dataMack @AshwiniChezhiyan @LizaNemchynova @revathi

Would be nice to have the regex tool allow you to drop original input field and report and error if any records fail to parse.

Version 2.0 of the publish to Tableau tool does not work for the initial authentication if Tableau Server has CORS enabled.  

This only impacts the UI for the tool that completes the sign in to Tableau Server and provides back the list of projects, data source names, etc. 

When CORS is enabled, a 403 error is received with a response of invalid CORS request.

If the XML on the tool is manually edited and the tool is run, it works fine to publish to Tableau, with or without CORS enabled. 

version 1.0.9 also works with no issues, but is not the ideal solution when users are on newer versions of Alteryx designer

Additionally calls to the REST API from a local desktop using postman or python work with or without CORS enabled. 

Based on conversations with Alteryx support, the tool was not tested with CORS enabled, thus the bundle.js file completing the authentication for the GUI must not account for Tableau Servers with CORS enabled. 

For those who build solutions with Tableau Server that utilize the REST API (e.g. like custom portals) CORS must be enabled to function, but it limits the ability to use version 2.0 of the publish to Tableau tool.