I've seen various solutions/workarounds but this seems to be a table-stakes ask? When scheduling a workflow I should be able to specify which parameter values to run with. Just two of many use case examples -
Use case #1 - a single analytic app could be scheduled multiple times, each schedule specifying a different line of business
Use case #2 - credentials, allow the user to schedule a workflow with their saved credentials. When their credentials change all they would have to do is update the schedule parameters
(If you know a better way I'm all ears, not the API thought that isn't a bad way to do it, just not super Easy)
I would like to see the enhancement of being able to schedule a start and stop time for specific jobs that need to run multiple times per day, so they don't run during the nightly backup periods of the Alteryx server. This can cause the daily backups of the Alteryx Gallery to fail. Currently SQL Server Management Studio/SQL Server has the function to able to schedule start and stop times for specific job. Currently Scheduler page on Alteryx Gallery/Server lacks this feature.
SQL Server Management Studio
Schedules on Alteryx Gallery/Server
Using current version of the server - you can see that there is no OAuth managed or published API endpoint for canvas delete (screenshot 1). However this API does CLEARLY exist as you can see if you inspect what happens when you hit the delete button (screenshot 2 clearly shows the API being called - but it requires user login security token)
Please can you enable this API for OAuth - the API already exists, it just needs to be exposed with the others.
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.
There is no good way to get server user credentials into a workflow without asking them for it in an App interface. It would be great if we could have a built in Constant that could be used to silently pass user credentials into a workflow for things like API's or logging user information.
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.
As a server administrator, I would like to have more control over collections. I have a user who is in charge of a collection out of office, and we have some users who need to get to be added to the collection to run workflows. As admin of the server, I would like to be able to add users to this collection, modify permissions, modify workflows, etc. This would be necessary both for when users are temporarily out of the office as well as if someone were to leave the company.
As your analytics work grows - you find yourself using the power of Alteryx to create shared macros. These act as an accelerator for a team because one team member can us a reusable solution created by another team member. For example - many teams need to get data out of JIRA (or some other system) so you create a connector that everyone can use.
That's going well - and now you have 20 teams all publishing canvasses to your server (possibly 100s of canvasses running in production) which make use of your JIRA connector - all good so-far!
BUT THEN - you discover an issue with the JIRA connector and you need to fix it and publish a new version!
It's at this point that you realise that the canvasses on your server which use your JIRA connector are NOT pointing to it, but they have made a copy and included this inside their canvas. So when you fix the problem with the JIRA connector - no-one gets the fix!
This is because every application uploaded to the server is a yxzp file, which zips up a COPY of all the shared macros and uses this in an isolated way.
So - in order to get the new JIRA connector (with the defect repaired) used instead of the old one you now need to:
- Download EVERY canvas on your server
- Unpack them all to expose the sub-macros being used
- Inspect them to see if they are actually an instance of the JIRA Macro
- Make a list of the owner and application IDs
- reach out by e-mail or phone to every one of these folk to ask them to republish their Alteryx workflow with your new version of the JIRA connector.
Please can we revisit this - we really do need the power of shared macros - and we also need the ability to fix and manage these like a product over time. This will have an impact on the engine (hence copying @AdamR )
- When you build a canvas using a shared macro - it doesn't store the macro itself, but rather a reference to the version on the server - unless you explicitly decide to break the connection and take a copy.
- When you check this canvas into the server - your application / yxzp does NOT include a copy of the shared macro - instead it has a reference link
- this means that Alteryx Server can now track which canvasses use this shared macro very simply
- When I fix this shared macro - I can then do an in-place update; or if the interface is not the same (i.e. different inputs or outputs) then this has to be a new version and the users will stay pointing to version 1.
This is how shared assets are managed in a micro-service world, which is the way that all of our architecture is going - and it seems important that we build this thinking into the Alteryx infrastructure too.
I was reading a post on the Community (http://community.alteryx.com/t5/Publishing-Gallery/Macro-sharing-Best-practice/m-p/38330) which reminded me of an idea that I had.
It would be really nice if a Gallery location could be used as a "Macro Search Path" so that macros don't need to be downloaded from the Gallery and saved locally to be used in a workflow.
So in addition to going to Options>User Settings>Edit User Settings>Macros and adding a local/network path, you could add your internal gallery information...
It would be useful if the Admin of a Private Gallery (in house server) could delete studios and/or members. Also, it's confusing that a member who's added also gets a Studio automatically set up. Members (for my purposes) are only supposed to be able to run apps in collections that I grant them access to. They should not get their own studio. Even if they can't use the studio (or even know that they have a studio), it's not very efficient to have all these studios show up on the subscriptions screen.
The ability to select a workflow or app within the Gallery web interface and change its name. This would maintain its historical run data, version control revisions, placement in collections, etc.
Use case: As a workflow or app continues to be developed over time, the name may need a revision to continue reflecting the workflow's function.
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.
As the Server Admin I'd like to have the ability to view ALL "Workflow Results" for all Subscriptions.This will give the highest level admin the ability to monitor all schedules (on the entire server instance) and monitor if they are unable to complete successfully (example- unable to allocate memory) and any other errors are occurring.
Knowing this information will help the server administrator understand if there are issues with the server itself (e.g. if we need more workers or to simply adjust actual server system settings..etc..)
Many people maintain valuable information in Excel files, and many organizations, like ours, also use SharePoint to store and share structured and unstructured information. We see most user-generated and maintained data in Excel files in SharePoint document libraries, and one of the great benefits of Alteryx is the ability to join that Excel data with other data sources. Unfortunately, the v11.0 Scheduler cannot resolve the UNC-style ( \\server@SSL\DavWWWRoot\site-name\document-library\filename ) addresses, so workflows that access this valuable SharePoint Excel data must be run manually. The SharePoint List Input tool can read the list-style metadata for Document Library files, but does not access the file content.
The Scheduler should be enhanced so that scheduled workflows can read Excel data stored in SharePoint Document Libraries.
When posting an app to the Gallery, if the app has, say, one PCXML output for the user to see, and one Excel file for the user to download, it would be helpful for to be able to specify which shows first to the user. For example, I have a PCXML that gives the user summary tables, and instructions on how to go to the drop down above and select the second report, click on the Excel icon, and download it. But if the Excel report shows up first, then there is no ability to give them instructions and many simply won't be savy enough to go find the PCXML in the drop down.
I'm really enjoying the new Save As functionality to push to the gallery, but had a request that would make it even more useful for me.
I saw that you can open workflows directly from the Gallery and edit them with version control, but it would be nice if it was possible to do a Save As on a local workflow and point it at an existing copy on the server. I need to maintain a local copy of my workflow for dev/prod separation, but currently my way to push to prod is to do a Save As to my Private Gallery, remove the existing copy from the company gallery, and then share my newly created workflow into the company gallery. This causes some headaches like no version control, switching out icons everytime, and overall just a messy way to push to prod.
It would be helpful if there was a way to overwrite an existing workflow in the gallery rather than editing it directly.
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.
Wanted to grab some attention here regarding the Alteryx gallery search engine (which also bleeds over into searching for schedules and jobs when troubleshooting).
Since a picture is worth a thousand words, I'm pasting two pictures (one attachment) of searching our gallery for the word "Contour" and the word "Signal". Both of these words are in the title of a single workflow - when I search for the word "Contour", the workflow pops up. When I use the first word in the workflow, which is "Signal", it doesn't pop up.
I appreciate all that Alteryx does, but I wouldn't think this should be a difficult issue to fix, and I would imagine there are other frustrations with the functionality here.
As large enterprises continually strengthen security around their system and data assets, we're seeing adoption of products like CyberArk's Enterprise Password Vault (https://www.cyberark.com/products/privileged-account-security-solution/enterprise-password-vault/ )
The system is essentially a central repository that secures and automatically rotates passwords for privileged accounts- things like a functional account you would use to run workflows against a certain database or set of systems.
It would be great if Alteryx could build both Server (Run As Account) and Designer (for individual database connections) integrations with a tool like that.
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.
The only reference I can find to this idea is here : https://community.alteryx.com/t5/Alteryx-Connect-Gallery/Share-Results-in-a-Collection/m-p/231 . It references that the feature of "sharing workflow results" was "on the Roadmap" in 2014. I did some searching through the current Ideas page and cannot find anything. I also reviewed the release notes since Alteryx 10.5 and cannot see that this was added.
A user approached me today with a problem of "Many people need access to the results of this data, and I want everyone to be able to see all the results". While you could potentially email these results to a specified user set, that would require maintaining both a collection and an email tool in the job, and could potentially cause notification fatigue if users only care when they go to the Alteryx Gallery. Similarly, results could be saved to a networked location, but that would require a user to go to two locations in order to find this information.
As such, having a toggle that allows users with permission to view a workflow, to also see the results of any/all users, would be huge.
I would like to collaborate with my team, but also maintain my own personal private studio.
Is that on the road map?
The shared data connections from the Gallery have been very helpful in centralizing data connection information between desktop users and their workflows when saved to the Gallery. The In-DB tools currently cannot take advantage of the Gallery Data Connections and require a completely separate setup that is both confusing and adds additional connection management work for creation/password changes.
It would be a great enhancement to Alteryx if all connections for the different types of tools could be centrally managed from the shared Data Connections manager found in the Gallery.