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:
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:
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.
This has probably been mentioned before, but in case it hasn't....
Right now, if the dynamic input tool skips a file (which it often does!) it just appears as a warning and continues processing. Whilst this is still useful to continue processing, could it be built as an option in the tool to select a 'error if files are skipped'?
Right now it is either easy to miss this is happening, or in production / on server you may want this process to be stopped.
I surprisingly couldn't find this anywhere else as I know it's been discussed in person on many occasions.
Basically the Formula tool needs to be smarter in many ways, but this particular post focuses on the Data Type component.
The formula tool, should not always default to V_String as the data type when entering data or a formula into the formula tool, it should look at the data type and estimate the most likely option.
I know there are times where the logical type might not be consistent in all fields, but the Data Preview and the Function of the formula should be used to determine the most likely option.
E.G. If I type a number or a date directly into the formula tool, then Alteryx should be smart enough to change the data type from the standard V_String to Int, Double or date.
This is an extension to the ideas posted here:
I often need to create a record ID that automatically increments but grouped by a specific field. I currently do it using the Multi-Row Formula tool doing [Field-1:ID]+1 because there is no group by option in the Record ID tool.
Also, sometimes I need to start at 0 but the Multi-Row Formula tool doesn't allow this so I have to use a Formula tool right after to subtract 1.
So adding a group by option to the Record ID tool would allow the user not to use the multi-row formula to do this and to start at any value wanted.
Love the new updates to the Browse tool in 2019.2! However, if you choose the option Open results in new window, which I do often so I can see my whole dataset, the search/filter/sort functionality goes away. Would be great if that new functionality also worked in the new window. Thanks!
Can't wait for the new base maps!
In-app screens, lot of space is wasted because components/tools can just be stacked one below the other.
It would great if we could also insert them horizontally.
Tags : screen, app, macro, layout, tools, UI
When inputting a CSV file via the Azure Data Lake File Storage tool the default behaviour is for the first row to be interpreted as data.
When reading the same file locally using the File Input tool the default behaviour is for the first row to be interpreted as headers.
Since the majority of files will include headers on the first row, it would be helpful to have the "First row contains field names" option selected by default in the Azure Data Lake File Storage tool, and this would also bring the defaults of this tool in line with the standard File Input tool.
Illustration below showing the issue:
The SalesForce Input tool is great.. but has some really bad limitations when it comes to report.
I think there are 2 main limitations :
A - It can only consume 2000 rows due to the rest api limitation. There plenty of articles about it in the community.
B - Long string such as text comment are cutout after a certain number of characters.
Thanks to this great article : https://community.alteryx.com/t5/Alteryx-Designer-Discussions/Salesforce-Input-Tool-amp-Going-Beyond... , I had the idea of going through a csv file export to then import the data into Alteryx.
I've done it using two consequent download tool. The first download is used to get the session id and the second to export a report into a csv in the temp folder. This temp file can then be read using a dynamic input workflow.
Long story short, I think Alteryx should upgrade the Salesforce connector to make it more robust and usable. Using the export to csv feature, this should enable Alteryx to be fully compatible with Salesforce report.
The Publish to Tableau Server tool is great.. but requires username and password. If you are using AD, there is a chance that your users don't have a password. In that case, you probably have a technical user that you share across the team. This is not an ideal situation and you loose the governance around the data.
Fortunately, there is an easy workaround. You can leverage personal token authentication : https://help.tableau.com/v2019.4/server/en-us/security_personal_access_tokens.htm
The advantage of this method is that it logs in with your user and your data source is uploaded under your name. This is still using the Tableau REST API so the changes to do in the current macro is MINOR.
Changes to do in the current macro :
1- Add a parameter authentication method with choices : Username/Password ; Personal Token
2- If Personal Token is selected, add two parameters : Token_Name and Token_Value
3 - In the TableauServer.Login supporting macro, improve the formula(13) to change the payload based on user selection. If Username/Password, keep it as is. Else use the syntax here : https://help.tableau.com/current/api/rest_api/en-us/REST/rest_api_concepts_auth.htm#make-a-sign-in-r...
This is quite a straight forward change but could help a lot of companies using Alteryx.
Can you please implement that changes to strengthen this tool ?
Thanks a lot,
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.
Please follow above link...
We are seeing a huge requests from users to support this feature...
Till 2019.4 version, Alteryx can't connect to a table if complete read access is NOT granted to it....
Other DataConnector tools des this action except Alteryx...
Please consider this as a Feature Request ..
Currently Alteryx does not support writing to SharePoint document libraries.
However there are success sometimes but not at other times.
Please see attachment where we ran into an issue.
See this link for additional information.
We need official support for reading and writing to SharePoint document libraries.
It's an important Output target, and will becoming more so, as Alteryx enhances its reporting capabilities.
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.
It would be great to have the below functionality in Alteryx.
A workflow is built in Alteryx and button click in Alteryx can be used to generate SQL code that can be ran on a specific database platform, such as SQL Server to run external editors such as SQL Server Management Studio. Thanks.
Alteryx Server was recently updated to allow TLS-mediated connections to the MongoDB persistence layer. This allowed us to switch off of the embedded MongoDB to a highly-available MongoDB Atlas cluster. To our surprise after the switch, when we went to edit our workflows that make use of the persistence layer's data (Server Usage Report, etc.) to hit the new Atlas cluster, we found that the MongoDB Input tool does not support TLS connections. This absolutely needs to be changed. Based on organizational constraints, Atlas is our only option for a HA persistence layer. We absolutely have to have TLS support for the MongoDB Input tool. There is no other way for us to natively query our server persistence layer in Designer. Please bring the MongoDB Input tool into alignment with the MongoDB connections that are supported by Alteryx Server.
It would be wonderful for Alteryx to be able to connect to and query OData feeds natively, rather than using a 3rd-party driver or custom macro.
OData querying is supported by quite a few familiar products, including Excel and PowerBI, SSIS/SSRS, FME Safe, Tableau, and many others. And the protocol is used to publish feeds from Microsoft Dynamics and Sharepoint, as well as many of the 10,000 publically available government datasets with API's (esp. those hosted by Socrata)
I didn't see it as in the Idea section, but questions and workarounds have been discussed in the community a few times (11/15, 3/18, 4/18), and suggestions seem to be just to buy the $400-600 ODBC driver from CDATA (or ZappySys), or I could use a VBA script in Excel trigger a refresh, or create my own Alteryx connector macro (great series btw, though most was beyond my understanding!)
While not opposed paying, kludging, or learning to program, they're just one more thing to build/buy, install, maintain, and break at the most inconvenient time 🙂
OData (Open Data Protocol) is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming RESTful APIs. OData helps you focus on your business logic while building RESTful APIs without having to worry about the various approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats, query options, etc. OData also provides guidance for tracking changes, defining functions/actions for reusable procedures, and sending asynchronous/batch requests. OData RESTful APIs are easy to consume. The OData metadata, a machine-readable description of the data model of the APIs, enables the creation of powerful generic client proxies and tools.
More info at at http://odata.org
In the Python 3.6/3.8 versions of SF Input Tool, the business name of an object is returned (e.g., Quote). In the now-deprecated Macro-based version of SF Input, the technical name was returned (e.g., Quote, Quote__c, SBQQ_Quote__c).
With the Python Input tools, there are multiple occurrences of "Quote" to select from with the SF Input tool. This is confusing and leads to "guessing" which object is the right one.
See attached screenshots.
My proposal is to add an option to the SF Input tool to allow the workflow developer to choose whether technical or business names should be returned.
While Alteryx allows for a proxy username and password in the settings, these are not passed properly to an NTLM proxy. Support for NTLM authentication would be incredibly useful for a number of corporations who utilize this firewall setup.
We currently have to either download via Python or cURL through batch commands called by Alteryx. Since Alteryx uses a cURL back-end, this should be a fairly simple addition to the existing download tool by allowing a selection of proxy server, port, and authentication method in addition to the proxy username and password. This could be done either in the tool itself or in User Settings.
I would like to see the Publish to Tableau Server tool updated to include the option of authenticating with a Personal Access Token in addition to Username/Password. The user would be able to toggle the login method and provided the necessary credentials for that method.
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.
Please update the Publish to Tableau Server connector tool to support Tableau's Ask Data feature. The data source must be recognized as an extract on Tableau Server in order for the Ask Data feature to work. Currently, all data source published using version 2.0 of the connector tool are recognized as a live data source. The work around is cumbersome and requires multiple copies of data sources to be created and managed.
I have recently added an Azure data lake v2. The Azure input/output connectors do not work with this version of the Azure data lake.
It appears that Alteryx adds ".azuredatalakestore.net" to the file path. This works for V1, but not needed for V2
any plans to configure a connector for Azure data lake v2?
At our organization we are required to change our passwords every few months forcing a change to my Tableau Server password. How does this relate to Alteryx? Well, every 90 days I have to change my password in the "Publish to Tableau Server Tool" for all of my workflows. This is quite a cumbersome process that could be eliminated with AD.
If you dislike manually changing your for each workflow that uses this tool then "star" this post!
The join tool currently does not allow case-insensitive joins, but the find/replace tool does. Additionally- even if both sides are identical, the join tool will not join "Sean's house" to "Sean's house" because of the non-letter character in the middle. Finally - if one side is a string(2), and the other is a vString(200) - even if you have a single identical character on both sides you get uncertain outcomes unless you force the type
Please could you consider amending the join tool to include 3 new options or capabilities:
- Case insensitive join
- Allow full Unicode character set in join
- Full match across text types (irrespective of string size) - this would allow a string(2) value to match to a string(100) value as long as the string(100) value only has the same 2 characters in it as the string(2) value
That would remove a load of work from every text-join that's being done on every canvas we do.
A lot of companies now are deploying on both AWS and Microsoft Azure.
Alteryx supports AWS S3 object storage out of the box, it would be important to support Microsoft Azure blob as part of the native Alteryx product as well.