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.
Admin settings for the Alteryx server are currently split between the Admin GUI in the gallery (screenshot 1 below) and a tool called "Alteryx System Settings" (screenshot 2 below).
Please could you move all of the system settings into the Admin section of the GUI. Not only will this allow an admin to administer the settings remotely (rather than having to be logged into the actual server with an interactive login which is needed now) - it will also consolidate them into one place which makes things easier for admins to ensure that all settings are set up correctly.
This could be done progressively - a little bit in every release - over the next couple of releases, it does not need to be done in a big reengineering or a massive big-bang release (in fact - progressive release is much more favourable since you learn along the way and big-bang releases are well known to be failure prone).
We have several clients that operate in a Multi-Forest environment due to mergers and acquisitions. Currently with Alteryx Server the only option we can offer them is to use Built-In authentication. A lot of corporate and particularly finance institutions prefer a single sign on approach and utilise Windows authentication to do this.
Would it be possible to add support for Multi-Forest organisations into Server to support organisations going through mergers and acquisitions?
This would really benefit us in selling Server in to organisations with complex structures and reduce friction in publishing or preparing workflows.
So, .YXI files are great, they allow a much simpler installation process of macros from the Gallery to your local machine and server.
However one problem; they are not supported to be hosted on the Alteryx Gallery. This means that in order to share .yxi files they have to be hosted on some other drive and then you have to have a workflow in the alteryx gallery which provides users with the download link.
This makes that clean process a bit less clean, and it also causes problems with big customers who cannot whitelist these share drives for which the .yxi files are hosted. I myself have had about 20 emails from one global consulting firm in the US requesting access to a macro, I can't link them to the content as they are blocked, and therefor I have to email them individually.
It's a tad tedious and ruins the 'install experience'.
If you don't know what I'm talking about you can follow my colleagues (Peter Gamble-Beresfords) blog here:
Please keep in mind that this is a suggestion from a container novice! 🙂
However, our situation is such that our release upgrade deployments are taking significant time to install, test and sign-off from DEV through PROD for the four main life-cycles involved in our server environment. Even if we script the deployment to save time, there's still manual configuration needed to confirm the new version works in the next server environment.
Similar to how Promote can deploy from DEV through PROD using images/containers, my suggestion is to package the Server components into images/containers that can be similarly deployed through the life-cycles. While the container with mongoDB doesn't need to move to the next life-cycle, the containers with the web server, load balancer, and engine nodes could move with the click of a button. And if needed, reverted to prior version with similar ease.
I forgot to ask about this idea at the UX lab during Inspire, but would be very happy to hear if it's already in the pipeline!
As a system admin, I need a simple, reliable way to back up the Alteryx Server without shutting it down first. A hot-backup (and restore) utility that includes a consistent copy of MongoDB plus any other server config files would allow me to do this.
If you are reading this idea suggestion, I hope it is not too late for you. Why allow the user to change the authentication method once the install is completed? What are the options to solve this?
One option would be to grey-out the "Authentication Type" section in the "Gallery Authentication" screen, so the user is not able to change authentication methods once after the first configuration is set. This would still allow the user to change SAML settings.
Another option, if somehow there is a reason why a user would want to change authentication types even though it is not supported, what about changing the layout to make it more difficult to change the authentication type.