So - one of the biggest challenges that we have with the MongoDB used by Alteryx Server is that we continually have issues with locking (where our admins have to go in and undo locks)
Additionally - the current implementation of MongoDB connectivity does not support full Kerberos authentication which means that we're on a non-compliant install (which in a large enterprise is an uncomfortable place).
Given that a very large amount of what the server does is transactional - it would make sense to have an option to use a large-scale SQL server instead of using Mongo. For large enterprise customers, there must be flexibility to allow the databases that they have large supported instances of (my strong preference would be MS SQL 2016).
MS SQL natively supports XML so all the canvasses can be stored in native format. Additionally, MS SQL allows very fast query across XML, and given the clustering and reporting capabilities in MS SQL, this would dramatically increase our ability to self-manage our infra.
Given that Alteryx is looking more and more at large Enterprise customers - a move to a large-scale clustered SQL env as the back-end would be a very positive move.
NOTE: as we consider DB options for a SQL backend - please consider your large-scale enterprise customers. For example - MS SQL or Oracle or DB2 are all much more prevalent in enterprises than databases like Postgres - so it's important to focus on the enterprise support for the DB that you choose.
As an Admin, I would like to be able to see, from the Gallery, a single place where the history of workflows that have been run is displayed. Right now I can only see workflows running or queued. I would like to be able to look back at past executions and see status, runtime, errors, etc.
This data is currently available in Designer on our Alteryx Server. But right now our system is just one environment. I'm not sure if when we expand to multiple Gallery and Worker machines where I will have to look for workflow history.
Also, Workflow schedules can only be seen in Gallery, and not Designer. So it would be nice to have everything in one place.
Given the need for administrators to be able to perform analysis and monitoring on server performance; user usage etc - it is necessary to provide full documentation for both the API and the database underlying the server so that admins can use this to good effect.
Although very limited documentation is available on the server API (https://gallery.alteryx.com/api-docs) what we're looking for is a much more fully formed and navigable experience like some of the examples below.
This will make building helper processes substantially easier; as well as allow admins to fully manage their environment.
Alteryx Designer is an amazing data tool but it’s partner, "the Scheduler" needs some much needed upgrades. The Scheduler interface that pops up from Alteryx Designer does need a complete make over. I’m not going to address this but rather focus on the functionality that if delivered makes the Scheduler much more useful.
Today I’m reading our Mongo db scheduler data using an Alteryx workflow and Tableau to show what’s happening on the Scheduler. This dashboard is what we refer to frequently to see the health of our companies data pipeline. I’ll share both files soon.
Here are the top 5 features for the Scheduler.
Why: At midnight we set off several workflows. We want to centrally manage which runs first based on a common ‘priority’ field.
Why: Some workflows only run on the main controller due to file system references. Also a worker can be tuned for CPU or Disk I/O and workflows that can benefit from this tuning. Selecting a disk I/O intensive workflow to run on a server tuned for Disk I/O would speed up our workflows.
FYI: We used the Runner tool for a short time to resolve this issue but learned quickly that the Runner tool is like a bull in a china shop and brought our server down. The runner tool as it is today is not an option for production work.
Why: This would allow you to run several workflows one after another. For example the first would read from a data source, the second would do calculations on the data and the third workflow would publish the data. All workflows are given a ‘workflow-number’ which can be seen in the scheduler list and read from Mongo db.
Why: Some workflows fail and if attempted to run again may work. This includes issues with locked files and workflows dependent on processes outside of Alteryx.
Why: Some workflows start to hog resources and need to be killed. If a new workflow is added this is a good way to protect the overall scheduled workflows.
Currently the InDB tools require to select a DSN that is defined on your computer.
This makes any workflow which uses a DSN incredibly painful to deploy to the server, since the DSN needs to be created on every worker node and for a large server environment this can mean creating DSN entries on 6+ worker nodes in prod plus prod server plus dev/UAT environment plus dev/UAT worker nodes.
Could we please change the InDB tools to default to DSN-less connections, where the connection persists the connection details in-line so that it can deploy to the server without a DSN setup (since all connection details are contained within the connection string)?
Currently when scheduling workflows, there is an option to schedule based on the calendar day but not on business day. For example, if I want to run a workflow on Business Day 1 of every month, it is not necessarily the first day of every Month. For the month of June 2019, Business Day 1 is June 3rd, since the 1st and 2nd fall on the weekend. Many departments run their processes on Business Days rather than Calendar days. Also factoring Holidays into consideration would be a plus since January 1st for example is a Holiday, Business Day 1 would fall on the 2nd.
We have the Local License Server installed. Right now, if a Designer user changes roles, or leaves the company, they have to release their license from their client-side machine. If they don't release it properly, and IT can't get us into their machines, then we have to wait 7 days for that license to roll off the server. There should be a way for a system admin to forcefully revoke someone's license.
Please support GZIP files in input tool in Server. This is related to https://community.alteryx.com/t5/Alteryx-Product-Ideas/Support-for-GZIP-gz-compressed-files-in-input..., but logged in a separate Idea because the staff indicated in the thread that they are planning support for GZIP in Designer only in 2018.2. We need it in Server as well.
Currently on Alteryx it is possible to add visibility of a subscriptions scheduled workflows to all members of that subscription.
What we would quite like is for the ability to turn on or off the ability to edit workflows within that subscription for all members.
As in if a member goes on leave, or leaves the company, or is ill, other members can edit, update and cancel the scheduled workflow as needed without needing to go through an admin for it.
This idea covers 2 things:
- Disabling certain tools for users
- Pushing out other tools
- If we want to disable a particular tool for everyone or for specific users - then we need to go to every single deployed machine and adjust settings or delete some DLLs.
- What we would need is to be able to take a user / group of users - and de-select certain tools or apply limits
- In our corporate environment - every designer needs to check in with the server before fully starting up. If it cannot connect to the server, it needs to terminate gracefully
- As the designer logs in - the first negotiated conversation is "What tools and capabilities and standard default settings should I have"
- If a useful tool is brought into our environment (like the JIRA connector here: https://gallery.alteryx.com/#!app/JIRA-Connector/58d87c2feffc2a0dd0b5ed8f or the CREW macros) - we want to be able to push these out to all the users
- Again - every designer checks in with the server first
- Then negotiates tools
- then downloads any missing tools or updates new versions of existing tools.
This kind of central server capability is essential in any enterprise deployment of several hundred seats.
We currently have the ability to store connections on the server which protects the credentials - however this capability does not exist for APIs for Sharepoint sites etc.
Please could you extend this to cover authentication for ALL connectors?
When saving a workflow to the gallery, none of the options I could choose from Set workflow credentials validates a workflow successfully when using database connections due to missing permission on the server (No specific Run As is configured on the Server). Apparently the server validates the workflow as following:
User is not required to specify credentials:No possibility to add credentials when running the workflow on the server. In that case, the workflow validates database connections with errors due to missing permission on the server. This error was expected.
User must specify their own credentials: This option is the most appropriate in case of working with database connections with regard to our use cases and security policies. Unfortunately this option is only enabled when the workflow is saved on the server already and run from the gallery. In case of the validation step when saving the workflow to the gallery, the server evaluates with the system user of the server. As a result, the validation fails. In that case, I expected the server to run the validation with the user from the Alteryx Designer.
Always run this workflow with these credentials: This option is not appropriate in terms of our security policy, since the workflow is permanently set with the users credentials.
So my suggestion would be to:
Otherwise is see no benefit of the validation feature (with respect to our use cases and security policies)
Please Enable OAuth 2.0/OpenID Support for Alteryx Server & Connect. Currently, it supports only AD , SAML .
Current SAML has limitations, Unable to import Security groups from LDAP/AD if SAML is enabled.
I recently ran into an issue where I had to remove my company's gallery from my Designer's Save As menu. Unfortunately, figuring out how to do this in the UI took far longer than I anticipated, and I actually blew it away using the registry. Eventually I found that when going to Save As, you can either remove it from the "Connecting" splash screen or you can press the gear from the Save As dialog box and remove the gallery that way, neither of which are an intuitive way to manage gallery removal. I would advocate for adding an entry to the Advanced Options menu along with data source collections for adding/removing/modifying gallery connections.
As this list of connection, dependency, and gallery management entries continues to grow, it may also make sense to remove it from "Advanced Options" and create a more descriptive "Data" or "Connections" menu or sub-menu. I think it would be helpful to see aliases, in-db connections, dependencies, assets, and gallery management all grouped together within the interface.
If you run an Alteryx app on your desktop or hard drive, a help button will appear in the bottom right. This button defaults to sending you to help.Alteryx.com, but you can adjust it to send you to any location by adjusting the app in the interface designer. This means that you could use the help button to send users to a location detailing how to actually use the app built. The issue comes that when you upload an Alteryx app to the Alteryx Gallery, the "help" button disappears. I propose that the help button be made available in the Alteryx gallery for apps so that designers can use it to direct users to locations detailing how to use the apps.
It would be helpful to have a central Logging tool for large & complex environments.
This would be useful to allow teams to have a central way of logging data transformation errors by error-type; severity; alteryx Canvas; etc.
Right now, there's a message tool, but this doesn't provide a way to create well structured central logging across a team; especially once deployed to a server environment.
With Version 2018.3, you removed the Autodetect SMTP button, and with it, have rendered the Email Tool virtually useless for many people, which is a shame because it is a critical tool for some of us to share reports produced in Alteryx.
In requiring an SMTP path, there are a host of authentication issues that need to be addressed, and we can't seem to figure out how to configure the path and From emails properly to allow the tool to work without errors.
My only solution at this point is to rollback to 2018.2 so I can continue to use the Email tool.
Please address this so we can use the tool as before, or provide the necessary configuration options to allow for proper authentication with popular email services (Gmail, etc.)
I love the gallery data connection feature - we're going through some big systems architecture changes, resulting in new locations for many datasets. Having a single place in the Gallery Admin area to update connection information works beautifully.
We're running into issues with the gallery-hosted data connections when trying to run some apps on our private gallery though. The trouble comes up when the gallery-hosted data connection appears inside a macro that's part of an app. We get an "Unable to translate alias" error when trying to run these types of apps.
If we have an app using gallery-hosted data connections that are outside of a macro, the gallery is able to resolve the connection alias fine and work properly. The issue only appears when the gallery data connection is part of a macro used inside an app.
We use macros a lot in our app development because it allows us to use standard methods for accomplishing common tasks. Using macros also enables us to set up automated testing workflows to make sure our processes produce expected results. As it is, we're unable to take full advantage of the gallery-hosted data connections because they don't work within macros, and instead have to continue using hardcoded connection strings. These are a bigger maintenance burden as our underlying systems evolve and are updated.
When we create a shared macro on the Gallery, the desire is that we are able to:
- publish this down to users simply and seamlessly
- Allow them to use these assets in their canvasses
- Allow them to simply update to the latest version of the asset on an existing canvas.
Unfortunately - right now the only way to distribute shared macros is to create a shared folder; and the only way to manage version upgrades of a shared macro is to manually find every single usage and manually upgrade.