Alteryx Server Ideas

When scheduling workflows in the gallery that are recurring, it would be beneficial to have  start and end times also. For example, when setting the frequency to hourly, if there is an option to run between 9 AM and 5 PM that would be great. This would prevent us to schedule workflows for all 24 hours and take up systemic resources when other important workflows could run instead

Current State:

Currently, all workflows and applications are in list-form within "My Workspace" (formerly Private Studio) and Collections.  In My Workspace, I might have workflows and applications that support a broad range of domain spaces and audiences.  As the developer (or Artisan), they're all in My Workspace, but shown as an exhaustive list with no categorization unless I name them to represent not only the function of the workflow/application but also the domain. 

Once those same workflows/applications are moved to collections, there can exist confusion over whether the workflow/application is intended for a schedule, manual run, or application.  Separating by naming convention gets messy and degrades clarity for non-developer roles.

Proposed Solution:

I would like to see folders, only one or two levels deep, be added to My Workspace and to Collections.  This proposed solution would not alter permissions, as those would be common for the parent collection and any assigned roles would function the same for that entire collection.  The solution is simply adding organization to enhance the user experience.

For example:  I might have a Collection that is intended for my Finance team....

Finance_Collection / Scheduled_ETL_Workflows / Workflows

Finance_Collection / Scheduled_Analytic_Workflows / Workflows
Finance_Collection / Applications_for_AccountingDepartment_ReceivablesTeam / Workflows
Finance_Collection / Applications_for_AccountingDepartment_PayablesTeam / Workflows
Finance_Collection / Manual_ETL_Workflows / Workflows

Finance_Collection / Manual_Analytic_Workflows / Workflows

Finance_Collection / etc...

All persons who have been assigned the role connected to the "Finance Collection" will still see everything in all of the folders but would have a better sense of what "workflows/applications" are intended for their use according to the folders the workflows/applications are organized into.

Value Added (Why This Matters):

• Enhanced user experience (easier to find the correct workflows
• The volume of roles and collections can be reduced, thus reducing Admin strain
• The solution does not impact roles and permissions
• Overall management of workflows and applications is enhanced for the Artisans

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I welcome input and feedback from the community and would appreciate your support if you find this suggestion useful for your Alteryx experience!

When I create a DCM Entry in Gallery, it would be great if the users I share it with would also be able to reference the credentials in their desktop designer when they sync their connections to the Gallery. 

Today, when you trigger a job using the Server API, it is considered as a manual run type. In fact there are only 2 type of jobs : "Scheduled" and "Alteryx_Run"

I think "Alteryx_Run" should be segregated into "API_Run" and "Manual_Run". This way in future version we could treat those type of job differently. 

We could also have more stats around the type of jobs.

In the interest of information and system security, would it be possible to provide a means to remove social media and email sharing options (Facebook, Twitter, etc.) from the SHARING drop down menus, such as through a configurable setting in the RuntimeSettings.xml file?

Currently there is no means (confirmed by Alteryx tech support) to remove these options from the sharing menu.  Sharing within the system can be controlled somewhat by controlling access to the system or specific output locations.Once the info leaves the system, there is no longer any means of control.

Providing a configurable option will allow locations to tailor to their specific needs.

If two users sit in the same studio and have multiple scheduled workflows in that studio, both users can see the results of those schedules under "Workflow Results" -> "My Jobs"/"Jobs Shared with Me" 

It gives both users in the studio good visibility of all the workflow results they have access to.

Now if we move to a 1 studio-1 user environment and share workflows and schedules via collections, this "Workflow Results" -> "Jobs Shared with Me" functionality is empty. Instead users have to go to each schedule individually to see the results from them there. 

So if you're in a 1 studio-many users environment, there is a single place to go to see all workflow results. But if you're in a 1 studio-1 user environment and sharing via collections, you have to go to infinitely many places to see the results of all the schedules shared with you.

So my idea is to have results from schedules shared via collections appear in Workflow Results.

Hi all, Per this thread, it would be helpful if we could have finer control of scheduled jobs in Alteryx Server: https://community.alteryx.com/t5/Publishing-Gallery/Resource-control-on-scheduled-jobs/m-p/61016/hig...

Specifically:

- Dependancies (one job should run after another in a chain)

- lower priority (some jobs should go down the priority queue to allow for others so that high priority jobs are not blocked by other less important ones)

Thank you Sean

It would be good to have these table headers sizable, so that it can be expanded to display complete Name (and other fields).

It would be great if i as a developer could create a DB alias connection and for it then to be available to other developers and distributed via the server.

Collaborative working like the above does seem rather limited at the moment.

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.

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.

CC:  @rijuthav; @jithinmony; @HengHe; @RajK; @ydmuley; @revathi; @Deeksha; @MPistone; @Ari_Fuller; @Arianna_Fuller; @JoshKushner; @samN; @avinashbonu; @Sunder_Sriram; @Rahul_Thakur; @Rahul_Singh

In an enterprise multi-node Alteryx Server deployment that has existed for many years and many upgrades, there are artifacts within the MongoDB that are unknown to Gallery Administrators. I envision a workflow or app that is developed by Alteryx that queries the MongoDB and looks for orphaned documents in the MongoDB across all collections. With 2022.3 there is a pre-upgrade check, however, it does not find all unexpected items within the MongoDB. Regular ongoing MongoDB health helps with overall management of the environment and could prompt for support cases before it becomes a problem during pre-upgrade activities.

Hello

Imagine the dream : Alteryx Designer Cloud with in database tools.

Well, that would be so great I won't write more....

Best regards,

Simon

Hello,


There are some tools that helps to monitor what happens on a website. Some are even open source (like matomo and open web analytics). Why not including one of those tools on Alteryx Server ?

There are of course a lot of feature but I like this one, an heatmap to show where a user click

Best regards,

Simon

Hello Alteryx Server Admins,

It would be fantastic to manage users' permissions with user groups. This would help manage all users with permission to create collections and schedules from a centralized page.

Something like this:

Best,

Fernando Vizcaino

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. 

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.

Hi, 

I think it would be extremely useful to be able to trigger an Alteryx workflow using Power Automate. 

The main benefit I see at the moment is automatically triggering an Alteryx workflow when the input data has been refreshed.

This would also enable a Power App to be added directly to Power Bi which can simply be clicked to re-run an Alteryx workflow then refresh the Power Bi dataset. 

In the Alteryx Gallery UI, it's possible to set up workflow credentials so that a workflow published to the gallery runs as a specific user.  

Unfortunately when that workflow is run from the Alteryx Gallery API, it appears to only ever run as the Alteryx Server Run-As account. 

Our developers in working with this figured out that if they called the (undocumented) API that runs the actual Alteryx Gallery directly, they can achieve what they want, but it seems a risky strategy.

The idea would be:

-Either unify the APIs so that the Gallery itself uses the same API to run workflows as what you present as the "Gallery API" (the eat your own dogfood way)

-Alter the Gallery API to enable us to run as a different workflow credential

Without this, we're forced to permission the run-as account to access anything that uses this method, which in turn then becomes a bit of a security hole (any workflow run will have access to everything that the run-as account uses)