Alteryx Server Ideas

Situation:

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!

Problem:

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.

Proposal:

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 ) 

Desired end-state:

- 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.

@AdamR ; @Treyson ; @SteveA @DerekK ; @BlytheE 

This idea has been touted in different flavours over the years (but not implemented), but I'd like to push it a little further:

1. Create the ability to collaboratively edit an Alteryx workflow - e.g. like you can edit Microsoft documents collaboratively. If the front-end is primarily an XML interface, this should in theory be possible?

2. Version control (not version tracking) - i.e. automatically state the differences in scripts between versions and allow for checking in and checking out of code

3. Power BI & Tableau Prep have the ability to see exactly what changes were made and to reverse steps to get back to a specific stage of development: it would be great to have a panel that tracks all the edits you've made since you started editing the workflow

In simple terms, a modern, interactive way for multiple developers to work together, but also to encourage the use of Server to "check in" your application and to avoid developers saving the same file over & over again locally.

We leverage Active Directory groups to manage user permissions to most of our company's resources like databases, file shares, applications, etc.  This idea is for the ability to manage a Gallery Data Connection via an Active Directory group.  In many cases, our AD group membership actually dictates what permissions a gallery connection should have, but we must manually add/remove users to the Alteryx connection to keep it synched with AD.

I think there are several ways Alteryx could be enhanced to support this; i.e. the AD group could be specified on the connection itself or it could be inherited from a Studio where the subscription is enhanced to support assigning AD groups to it (which could benefit other areas of Alteryx).

I'm told by Alteryx support that this functionality is unsupported but to post the idea here.  If anyone knows of workarounds to this limitation I'd certainly be interested!

As an admin - would like to have the following features on the Gallery

1. add summary cards to TOP of user page that show same summary as diagnostics page

2. "export to excel" icon 

3. ability to filter date

4. allow selection of ALL

5. allow me to default my settings choice so its always "all" - screen shot below

API that allows to specify the workflow version to download.

An example would be where a user has a scheduled workflow that runs at regular intervals and they might want to look at the logs from the results from a specific date. Having the ability to filter the date column would help with this, as the only other alternative at the moment is manually working through the pages.

One of our Server customers has a need to disable all schedules temporarily across all worker nodes.  I do not see an easy way to do this unless we go into each worker's settings and disable from there, but this is not ideal.

The reason is for scheduled maintenance windows during a large upgrade or migration.  Currently stopping the Alteryx Service on each worker is time consuming.

Thank you! 

Currently, the API V3 endpoints does not have anything for Data Connection Manager (DCM). Create an endpoint to allow users to add/delete/update and list data sources, credentials, and users of DCM data sources. Also include an "admin" endpoint that can list all of the above for the entire server.

The admin screen of Alteryx gallery does not have an admin function for DCM sources, its users, and credentials. This can cause visibility issues during audits of the gallery. An API endpoint can alleviate this issue until it is added to the UI.

It would be very useful to have a standardized method to set up notifications to the server admins and to the job owner themselves if an alteryx canvas fails (error).

My understanding is that currently the only way to do notifications on failure for every canvas is for every canvas to individually set up events.   On a large implementation, this becomes very difficult to manage.

I would suggest a service split to simplify maintenance actions in the Alteryx Server.

Split Alteryx Service into 5 services:

 Alteryx controller

• Dependencies: Alteryx Database
• Purpose: Controls job submissions
• Meaning: The Alteryx controller Service stopped means neither the users or the scheduler can submit new jobs

Alteryx Database

• Dependencies: N/A
• Purpose: Database
• Meaning: The Alteryx Database Service stopped means all the platform is down

Alteryx Gallery

• Dependencies: Alteryx Database
• Purpose: Controls the Web UI
• Meaning: Alteryx Gallery Service stopped means the gallery web page is down

Alteryx Scheduler

• Dependencies: Alteryx controller, Alteryx Database
• Purpose: Controls the scheduled jobs
• Meaning: The Alteryx Scheduler Service stopped means the users can still submit jobs manually but scheduled jobs wont be submited

Alteryx Worker

• Dependencies: Alteryx controller, Alteryx Database (only applicable if the server where the Alteryx Worker Service is running the Alteryx controller)
• Purpose: Executes the jobs
• Meaning: The Alteryx Worker Service stopped means no job will be executed on the node

This service split will help perform some maintenance tasks and enables the Platform Administrators to shutdown the platform correctly shutting down the services in the correct order.

Usage Example 1 (Cold Backup):

• Stop the controller so no more jobs can be submitted
• Stop all the workers
• After all the workers have stopped the Alteryx Database Service and the rest of the remaining services can be shutdown
• Preform the Cold Backup
• Start the services

Usage Example 2 (Changes in the worker configuration - By doing this the users will still have access to the gallery and their jobs):

• Make changes in the worker configuration
• Restart only the worker service

Usage Example 3 (Changes in the Gallery Page or Configurations):

• Stop the Gallery Service
• Make the changes
• Start the Gallery Service

Hi Server users,

It is amazing to know the permissions we have when accessing our own profile, but sometimes that is not enough. Knowing your server role is needed to perform a few tasks and it would be fantastic to have something simple like the example below.

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.

Greetings Server friends!

I was talking with @KevinP in the Solutions Center at Inspire and we talked a lot about how Server has been evolving over the last several versions. I'd like to request that end users be able to select workflows or applications shared with them as "Favorites." It would be great for ServerUI to offer a separate section for these selected "favorites" so that the end users can have a single go-to place to access their most frequently used apps.

 @JohnPelletier 

Currently, in order to run an app via the API, you have to have uploaded the app to your private studio. Frankly, I don't find this function useful because you have to download then re-upload an app in order to gain access to the API. The API would be more useful if when an app is shared with you (or a collection is shared with you), then it would also allow for that app to be run via API by the user it was shared with. Right now, the only person who can run the app via API is the user who originally uploaded said app. 

In prior versions, Gallery Admins could easily and quickly reactivate users that were deactivated (e.g., and employee leaves the company so we inactivate their Gallery account, but then they come back to the company in a few months with the same name and email).  

Now, the only way to do this is to edit the Mongo page.

We need a way via the UI to reactivate users, like we did in the old UI.

I suggest adding an option in the current User List/Grid to be able to filter for Inactive users.

It would be nice if the Gallery Admin could download the workflow from the workflow page within the UI, without having to run API calls or having to add himself temporarily to someone else's studio. 

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. 

Currently, Alteryx Server lacks rich job scheduling functionality to other products like Control-M and Informatica's Scheduler

Feature Requests:

1) Ability to configure job retries on failure without having to rerun the workflow based on a  event trigger: https://community.alteryx.com/t5/Alteryx-Designer-Knowledge-Base/How-to-run-a-workflow-from-an-event...

There are common occurrences where a workflow may fail to connect to Input sources and a retry would normally resolve the issue. 

2) More user friendly way to setup dependencies between scheduled workflows.  For example, if workflow A fails it triggers workflow B to run.  If workflow B runs without errors, it triggers workflow C to run.  Currently, we would need to configure this based upon events.  A complex chain of scheduled workflows becomes difficult to manage and scale.