Alteryx Designer Desktop Ideas

While I strongly support the S3 upload and download connectors, the development of AWS Athena has changed the game for us. Please consider opening up an official support of Athena compute on S3 like support already show for Teradata, Hadoop Hive, MS SQL, and other database types.

Alteryx is brilliant at handling dates and understands them natively. Very often businesses want to analyse money, and in all sorts of ways. In Alteryx if a column contains $123.45 Alteryx thinks it is a string, and one then has to mess around converting it to a number. Alteryx should recognise that anything like $123.45 or €123 or £1,234,567 is actually money and is a number not a string. This could be achieved either by  having a money datatype (like MS Access) or if that is too hard, a function that converts a string version of money into a number irrespective of padding, commas or decimal points.

Regards

Mark

When working with APIs it is quite common to use the JSON parse tool to parse out the download data which has been returned from the API. However the JSON data may be missing key:value pairs as they are not in the response. This causes issues with downstream tools where there are missing fields. The current workaround for this is to use either the Crew macro Ensure fields, or union on a text input file to force the missing fields downstream.

The issue with this is:

1) Users may not be aware of the requirement to ensure fields are present

2) You need to know the names of all the fields to include in the ensure fields macro

Therefore the feature request is to add an option to the JSON parse tool to add the model schema as an input.

For example with the UK companies house API, to get a list of all the directors at a company the model schema is

{
    "active_count": "integer",
    "etag": "string",
    "items": [
        {
            "address": {
                "address_line_1": "string",
                "address_line_2": "string",
                "care_of": "string",
                "country": "string",
                "locality": "string",
                "po_box": "string",
                "postal_code": "string",
                "premises": "string",
                "region": "string"
            },
            "appointed_on": "date",
            "country_of_residence": "string",
            "date_of_birth": {
                "day": "integer",
                "month": "integer",
                "year": "integer"
            },
            "former_names": [
                {
                    "forenames": "string",
                    "surname": "string"
                }
            ],
            "identification": {
                "identification_type": "string",
                "legal_authority": "string",
                "legal_form": "string",
                "place_registered": "string",
                "registration_number": "string"
            },
            "links": {
                "officer": {
                    "appointments": "string"
                },
                "self": "string"
            },
            "name": "string",
            "nationality": "string",
            "occupation": "string",
            "officer_role": "string",
            "resigned_on": "date"
        }
    ],
    "items_per_page": "integer",
    "kind": "string",
    "links": {
        "self": "string"
    },
    "resigned_count": "integer",
    "start_index": "integer",
    "total_results": "integer"
}

But fields such as "resigned_on" are not always present in the data if there are no directors who have resigned. Therefore to avoid a user missing the requirement for unidentified fields needing to be added, if there was an optional input which took the model schema and therefore created the missing fields would greatly improve the API development process and minimise future errors being encountered once a workflow is in production.

CI / CD is critical to any production level process, especially when multiple authors are contributing new features to the same workflow. Currently, multi-author editing of workflows is extremely difficult, and something that would be aided greatly by using git to control different branches of ongoing work. Luckily, that's something we can already do today! However, the ability to test before merging a pull request is critical to modern CI / CD pipelines. For this, it we need to be able to run a headless workflow from a CI / CD environment. Also, having the ability to pass in parameters to the workflow would allow for robust integration testing - something that isn't straightforward today without running on production environments. 

We have a large SAS Programming team that keeps most of thier data sets in a Unix environment. A more robust ODBC connection to this data would greatly enhance our use of Alteryx. The current SAS odbc Driver tends to lock Alteryx up. Creating edits to the connection also tends to lock ateryx up to an unrecoveable point.

In normal output tool, when file type is csv, it is possible to custom select the delimiter.  It would be great to be able to have the same option in the Azure Data Lake output tool, so for example you can write a pipe delimited file to your ADLS storage account.

We store valuable data in our MS Teams sites (which are sharepoint folders behind the scenes). Currently, there is no way to connect to sharepoint directly (only if I sync sharepoint to my local drive, which is problematic and doesn't work on Alteryx server).

My recommendation is to have a sharepoint connector which works on both the desktop and server.

Thanks!

Hi Alteryx Team, 

Now, Connect In-DB cannot use the data connection in gallery.

User need to input those DB info as well as the login and password.

I suggest to enhance the Connect In-DB tool, so that can select/use the gallery data connection. 

From enterprise point of view:

1. No database credentials and connection properties be shared to designer user. It can reduce the risk from abnormal access. 

2. Easy to manage the access control by Alteryx Admin in gallery. Can assign the data connections to different group of users. More convenience for audit.

3. Easy to maintain the data connection by Alteryx Admin in gallery. For example, reset the database password or update the connection properties . 

On the other hand, it is better to setup in-DB data connection in gallery. 

Best regards,

Samuel

As Tableau has continued to open more APIs with their product releases, it would be great if these could be exposed via Alteryx tools.

One specifically I think would make a great tool would be the Tableau Document API (link) which allows for things like:

- Getting connection information from data sources and workbooks (Server Name, Username, Database Name, Authentication Type, Connection Type)

- Updating connection information in workbooks and data sources (Server Name, Username, Database Name)

- Getting Field information from data sources and workbooks (Get all fields in a data source, Get all fields in use by certain sheets in a workbook)

For those of us that use Alteryx to automate much of our Tableau work, having an easy tool to read and write this info (instead of writing python script) would be beneficial.  

Not sure what detail needs to be added.  This is obviously a widely used RDBMS.

Current State:  When a macro contains nested macros the only method that reliably works to share them is via yxi (which I fondly refer to as my wixies). 

Future State:  Allow macros published to the gallery be their own tool palette so that when I or any user connects to the server the macros are there and just work, no import, no visible install just a single set of tools that work on that server. 

Side task - also get export to yxi 

Would it be possible to update the SalesForce input tool to support API version 49 or later.

Changes were made to the way recurring events are handled in the SalesForce lightning update and the current salesforce input connector does not include all events when extracting.

Pardon the length of this post, but I have been working with Alteryx since version 2.0 (11 years) and have been accumulating a wish list ever since.  Some of these suggestions have been made in the past but have yet to be embraced.  This is the first post for the first 'idea' but, as I said, this is a wish list that has grown since I was first introduced to Alteryx. More posts will follow.

I will break this into sections to hopefully make the suggestions easier to categorize and digest.

Application interface - Since I was introduce to Alteryx, the application interface (what is presented to users) has remained rather stagnant and, with the rumored push to adopt HTML as a replacement for pcxml, could benefit from the following additional settings. I suggest these based on the fact that dot Net classes for interface controls are readily available in Windows which allow for manipulation of each of the controls attributes.

1. The ability to set 'style' attributes for each of the interface tools in the application interface (font-family, font-style, font-size, font-weight, color, etc. This could be presented to the developer as an additional (perhaps optional button) in the Configuration panel for each interface tool as below:

These settings would be specific to the type of interface tool and to how the individual tool would layout and/or be styled relative to the application interface window. One layout option, applicable to most interface tools, would be where the label would be relative to the object itself (top, bottom, left, right). The CSS could be stored in and interpreted from the XML of the yxwz file referencing the ToolID of the Node in a section of the XML hierarchy called <CSS> or something standard.  An option to alter the default CSS could be displayed with a radio button control so that if not selected, the tool would fallback to the default system CSS of the tool.  This default could also be set in System settings so that a consistent interface could be defined across the enterprise.

2. Moving to the actual window that displays when the application is opened, a lot of the same concepts could be applied to the Interface Designer pane.

Attributes that could be set could include position on screen when opened, width and height of the window, and all the attributes of a dot Net form.  The same radio button strategy used for individual interface tools could be employed to use or not use system defaults.

3. In the UI, it would be nice if there was additional flexibility in how the interface tools could be laid out.  Along with the relative position of labels for each control, being able to layout controls horizontally as well as vertically would allow for a more organized interface.

 The Radio buttons would work as normal with the Text Box controls inside each Radio button and only displaying when the button is selected.

I realize a lot of the current development in Alteryx is focused on the new Alteryx Connect and being able to attach to more data files and services. But, if there is still also a concerted effort to move from what could be considered a legacy proprietary mark up language, pcxml, to a more robust and universally accepted mark up, html and css, then, in my humble opinion, expanding the options for developers to design more user friendly and customizable applications to a standard 'style' across the enterprise, both on the desktop and in the gallery, is a worthy endeavor.

Thanks for your attention.  More to follow.

Dan

In an enterprise environment, or a reasonably sized BI team - you want a degree of consistency on how workflows look and feel.   This increases maintainability; portability; and also increases the safety (because like well structured source-code - it's easier to read, so it's easier to peer-review)

Looking at all the samples provided by Alteryx, they all have a similar template, which makes them very easy to use.

Could we add the capability for larger BI teams to create a default canvas template (or a set of templates) which enforce the company / team's style-guide; layout; and required look-and-feel?   

Thank you

Sean

I've come across multiple requests for help that relate to dates.  Having to know that "2016-05-04" is the only way to get May 4th, 2016 into a date field is sometimes a challenge for new users.  When they begin to use date functions and now have to learn adding and trimming etcetera the complication factor increases.  Then we date time format and have to do all of this in English (my one and only language), makes me think that there is room for improvements.

Using other data viz tools like Tableau, we often plot yearly timeseries of data onto the same line chart so we can quickly compare year-on-year differences.  All data viz tools seem to have complexities but the logical approach is the same.  What you do is map all the years data to a relative year, i.e. this year, and then give each year it's own title.  See the example below snipped from a Tableau dashboard:

In this example 7 years of data have been plotted on the same chart.  Note the x-axis,  In Tableau we are able to format the X-Axis labels to only show month and day (Mon-D).  This removes the common relative year, i.e 2019.

As expected, Alteryx is awesome at preparing data to do this kind of thing.  Using the interactive charting tool you can build really nice charts.  However there is currently no way to format the X-Axis label, you must show the relative year too, as shown in the picture below (snipped from the browse tool, outputted from the interactive chart tool):

It was really easy to prepare the 5 year min, max and average lines, which is almost impossible to do in Tableau!

My idea in a nutshell is, please change the interactive chart tool so that the labels on the axis can be formatted to the user's choice, i.e. in this case formatted from datetime to "%B-%d".

Please note, the workflow i'm building in this case, is creating 3 line charts of related data, each by year.  The end product is a daily email sent to users.

Thanks, nick 

A simple, very simple idea that can save a few clicks for everyone and that costs less than 1 hour of development :

Just display all the tool categories on a fresh install. There is not need at all to display only a few and that's the first thing I have to do on every fresh install.

Today, any Alteryx tool with "Select" functionality has an option for "Dynamic or Unknown Fields" which, when checked, allows any new fields to pass through that tool.  This is a great function for most of the tools as you can allow workflow updates to pass through the tool without issue.

However, in the Join tool, there are some use cases where there is NEVER a reason to pass new fields from one side or the other into the tool, but you might still want new fields from a primary process.  Examples being something like a lookup/cross-reference to do an inclusive join, where adding new fields to the lookup might inadvertently pass these downstream.  Having the option to only allow unknown fields from one side through would greatly enhance this output.