This post illustrates the current state of how the Gallery and Scheduler interact with time zones as of V11.7. The behavior it showed in that test is unintuitive and may lead to issues with setting schedules correctly. One possible correction would be to unify all times on the server to server time, but I think we can do better.
What I suggest instead is to add time zone as an option on the scheduler. This way users that set schedules don't ever have to wonder at what time the workflow is actually going to run. That information can also be passed through to results such that users that want to make sure a schedule is working as planned don't have to back track and figure out if 5pm means 5pm their time or server time. Finally, it would allow a more intuitive way for an employee in Denver, CO schedule a workflow such that his or her boss in Irvine, CA receives the resulting report exactly when needed/expected.
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?
As users change roles; or possibly even leave the firm - we need to automatically manage the ownership of their and their permission.
- We need to be able to export all permissions and ownership of assets by user using an API
- We then need to be able to revoke permissions using an API (we have a central entitlement management process that this can be tied into)
- we also need to trigger a revoke on all licenses via API.
If done within Alteryx server:
- When a dept code on a user changes; or user leaves - trigger an invalidate on all assets.
- Workflow to both the primary and secondary owner to ask for a new owner
- Also automatically trigger a revoke on all licenses
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.
Currently, this is completely manual with whoever is assuming the schedule creating it under their profile and then the old schedule being deleted.
This can happen often in organization where a user leaves the company or assumes a new role requiring some else to maintain those schedules. It would be convenient if there was an option to reassign the owner of a schedule to simply this process.
For a given DB connection - there's a need to be able to specify the owner for this specific connection.
Reason for this is that the credentials for a given DB are not all managed by the central admin team - so we'd want to say that a given DB connection is owned by a particular person so that this can be updated frequently as passwords change.
For resilience - our particular policy would be to have 2 owners so that if one person resigns or changes roles, it invalidates the primary and reverts to the secondary - and then asks the new Primary to create a backup owner.
I have three team members all in the same private studio. We can see each others' workflows. However, when looking at a workflow that another team member has published to the gallery, it looks like:
This is a massive impediment to collaboration because my team handles ETL for most of the company. If a user complains that their data isn't up to date, whoever receives that support ticket needs to be able to see if the workflow is actually running and whether it was successful or had an error during the last run.
Preventing a team from seeing this for each others' workflow schedules and results means that the only person who can deal with an issue is the person who originally made the workflow. Which makes the idea of a shared private studio wholly pointless as we may as well be operating in different universes.
Please create a studio-level setting where all members of a studio can see all schedules and results of all workflows in that studio.
When an artisan moves positions (within or external) away from their current responsibilities, their collections and workflows should be able to be transferred via an administrator to another user.
In order for us to manage the large number of canvasses on our server - we need to add the ability for Admin teams to require additional attributes on every canvas:
For us, these mandatory attributes would be:
- Which team do you belong to (dropdown)
- What business process does this serve (dropdown - multiselect)
- Primary & secondary canvas owner (validated kerberos)
For the ones that have dropdown lists - we can provide the master data into a drop location or into a manually configured list on the server.
Currently Alteryx 11.x+ does not support Gallery data connections for In-DB connections, it would be nice to have these In-DB connections on Gallery thus providing ability to easily collaborate with others when using these In-DB connections. Right now we are saving to .indbc file and sharing that file.
When restoring an Alteryx Gallery instance to a second box for test & dev it's highly likely that you don't want all your workflows scheduled from your production instance to run in your secondary instance.
However there doesn't currently seem to be a kill switch that you can implement up front to stop your scheduled workflows from running. The only way to disable scheduled workflows in your test gallery is to manually delete them all, which is annoying when you have hundreds.
It would be great to have a config flag to disable scheduled workflows before the service is started.
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.
In regulated environments, like banks, there is a requirement to fully segment Alteryx Jobs so that people on either side of a Regulatory Wall cannot access each other's canvasses or results.
As an example:
- Public vs. private side in Broker/Dealer banks
- Compliance or HR or Finance need to be segmented from all other areas in most banks
What is needed here is for any canvasses belonging to each of these walled-off areas to be controlled so that they cannot be shared across the wall, and results cannot be viewed across these areas. This also means that the Gallery Environment needs to be capable of being segmented fully within 1 installed environment.
This idea is to allow users to configure the file view option for a workflow running in the gallery that produces file outputs. Today, there are two views that a user can toggle between (see attachment), but I don't believe there's a way to change the default view. This idea is to change the setting as either a global gallery setting, on a workflow-by-workflow basis, or both.
We have end users that miss the drop down menu (and the file count next to the drop down, and the label we've added in the analytic app that says there will be two output files, and...), so they sometimes miss the second file entirely. Setting the default view to the "list view" rather than the drop down view could help alleviate that pain.
Note: The screenshots in the attachment show two Excel files that could be combined into one file with multiple tabs. This is a pain point for other workflows, as well, that produce outputs in multiple file formats.
One of the issues that we have with Alteryx jobs in prod (and also Tableau, coincidentally) is that often a canvas is built to serve a need at the time, but after a while it's no-longer needed but it continues to run and consume server resources.
Can we add the option to our server environment to request recertification that a particular job is still needed every X months.
This will achieve 2 useful purposes:
- if the job is no-longer needed then the user hits "No thank you" and it's then taken off the scheduler which reduces server loads
- Alternatively - the user may realize that this should have been handed over to a new team or owner, and they can then make this change based on the recertification prompt.
I'm pretty certain that this would help to manage the inevitable build-up that happens on server environments where jobs build up until the server starts thrashing and the admin team then need to go out to all the users to do this recert process manually.
I have been trying to scan all of the workflows that are stored in the gallery and wrote this community post about it. Some Alteryx employees reached out to me directly to see if they could help solve my problem. We ended up with a somewhat wonky roundabout solution (that I haven't implemented yet) by downloading yxzp files through the Gallery API, unzipping them, then scanning the workflows as xml. I think the process could be greatly simplified if Alteryx had a set of Introspective tools.
The introspective tools would use similar, if not the same, processes that Alteryx already has in place to pull data from the gallery/server itself. The set of tools would be most useful for Server admins or people that are trying to build meta-workflows for Alteryx to make things easier for their users. Similar to the solution to my problem above, most of this functionality can be worked around by querying the Mongo and/or scanning engine logs. The Introspective tools would simplify this process greatly, especially when it comes to joining records from the Mongo and collecting workflow-internal data.
Since the tools will have direct access to the gallery/server it would make sense that they would only be available to machines with server licensing or could be made available if the user has a high enough permission level in the gallery they are trying to obtain data from.
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.
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.
From a security standpoint, it is important that all users are authenticated when accesing the Gallery on Alteryx Server and using local accounts. There shgould be an option available to force user to the login page rather than the public Gallery. Users going to the Alteryx server URL should be presented with the login page by default before being taken to the Gallery, rather than seeing the public Gallery and needing to click Sign-in in the upper right corner.