This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
It would be *really tight* to have a drop down interface tool that would support auto completion based on a odbc connection to a table/column or ajax call. I recently had a situation wherein we need to give the users the ability to select an address, then run a workflow. But the truth is, our address data is terrible, and what I really needed was to be able to let the users start typing the address, then give them a list of choices to pick from, they pick the correct (but usually wrongly formatted) address, and then I send that value into the workflow.
I could not find a decent way to give a gallery user a reliable way to pick an address from our list, so eventually wound up having to write an ajax piece to handle the auto completion, capture the user input, then post to a service that would in turn, interact with gallery through the API, get the response, and send it back calling page, and back to the user. A significant amount of work to put into something that is an exceedingly common web operation of auto completion.
This would make a lot of gallery operations flow so much more naturally.
In the same way that many default tools automatically generate annotations when they are dropped into the workflow, or their configurations are modified, there should be a way to add custom annotations for custom made macros.
I'm adding a 'Dynamic Input' tool to a macro that will dynmaically build the connection string based on User inputs. We intend to distribute this macro as a 'Connector' to our main database system.
However, this tool attempts to connect to the database after 'fake' credentials are supplied in the tool, returning error messages that can't be turned off.
In situations like this, I think you'd want the tool to refrain from attempting connections. Can we add a option to turn off the checking of credentials? I assume that others who are building the connection strings at runtime would also appreciate this as well.
As a corollary, for runtime connection strings, having to define a 'fake' connection in the Dynamic Input tool seems redundant, given we have already set the 'Change Entire File Path' option. There are some settings in the data connection window that are nice to be able to set at design time (e.g. caching, uncommitted read, etc.), but the main point of that window to provide the connection string is redundant given that we intend to replace it with the correct string at runtime. Could we make the data connection string optional?
To combine the above points, perhaps if the connection string is left blank, the tool does not attempt to connect to the connection string at runtime.
I frequently make analytic apps for my clients that requires them to enter information or parameters to the workflow via a prompt before running. The user could be entering codes that will affect a certain filter or it could be a prompt to browse to the new source file required to run the workflow. In order to make adjustments to the workflow itself, I need to work in Debug mode so that I can see the data as it passes through each node in the workflow. Once I am done making all of the changes in debug mode and I am satisfied with how it works, I then have to remember each change I made, and copy and paste each tool and its contents over to the workflow that I am debugging. This is a pain because it is like I am fixing the workflow twice. A good solution to this would be allowing the user to apply changes made in debug to the workflow you are debugging, so that there is no duplication of efforts!
One major improvement in version 11 is that you can now schedule workflows directly in the Gallery. One thing I miss though is the ability to see the whole log from the workflow (messages, warnings and conversion errors).
I have made a workaround by using the list runner (Crew Macros), but I think this should be a functionality on the server itself.
To see the workaround and the expected output, you can watch this video:
This idea is concerned with suggesting values based on text box entry in an analytic app. This would be an autocomplete within the text box interface based on matches to a list of connected values. For example, if someone was posting "805 Wells Road" it would expand the text box window and supply potential matches to click on.
Hello. While working at my company it has come up a few times that An Interface tool that acts like a standard "grid" would be extremely helpful.
This tool would allow users to update data that has a logical link to each-other like a stanard "row". Below are a few very simple examples where this would be extremely helpful.
#1) An application is being used as a file System ETL that has an interface that allows users to select what data to pull from a flat file and store in a database. The users can pick which 'columns' to keep by choosing the following information. The column name, type, and final database location of that column.
In this case a user needs to enter 3 key pieces of field information that have to relate to eachother.
#2) There is a table in a database that has thresholds for a specific law at the state level. (for Example: All loans in Florida must have a loan balance < 300k). However these laws can be updated, and the end users want the ability to #1: See the data, and then #2: Update it if the laws have changed.
A grid in this case would be perfect, as they could query the data to see the 50 states and specified limits, and then change the data in the "limits" column in order to update the database.
The previous 2 examples are pretty simple examples, but I have run into this request a few times from my personal experience, so figured I would see what everyone thought!
Just as a side note while we're on the topic of the Date Interface tool; it is really misleading the way "Today" stays outlined even after you click on a different date. I always second guess if it took my click or not.
It would be great if we could set the default size of the window presented to the user upon running an Analytic App. Better yet, the option to also have it be dynamically sized (auto-size to the number of input fields required).
It is important to be able to test for heteroscedasticity, so a tool for this test would be much appreciated.
In addition, I strongly believe the ability to calculate robust standard errors should be included as an option in existing regression tools, where applicable. This is a standard feature in most statistical analysis software packages.
I have an app that a team at my company uses to (sort of) quickly verify transactions. Our legacy VBA application was pretty slick, but in Alteryx it is fairly clunky.
I can not figure out, after a reasonable amount of searching, how to get the Alteryx app to display data before inputs are added. This seems like such an obvious feature-- I have written many Shiny apps that do exactly this. The current Alteryx app is very inefficient. The user must run one app to select a case to review. That app downloads a pdf with the info on it. The user must then run another app that closes the case with the needed information. This process is very slow and inefficient and the users are starting to migrate back towards 2 excel spreadsheets.
We need a way to display a data table or spreadsheet (or whatever) on the app itself. The workflow needs to be: Open app, select case, data pops up, off-app work, cases are updated and saved into the ledger. If this solution is available, please show me how to do this. If this is not available can the feature request be considered.
Would it be possible to add additional sections to the 'Summarise Tool' such as one for dates so that you might be able to group by Year, Month, Quarter, Week or a combination of all these. There are other extensions that could also be considered such as group with nulls or without that would make this tool far more usable and not dependent on data manipulation prior to it; you might offer to have all nulls grouped and called something else for readability and this shouldn't be very hard at all to implement.