Alteryx Server Ideas

When adding jobs to the queue via API call, you currently cannot specify the name of the job.

Running the job directly from gallery allows this as in the picture below, but there is no setting to do so in the API.

When a workflow is used in many different situations, being able to specify a name for the individual run will make tracking and troubleshooting easier.

Enhancement for the ability to trap errors at the tool level, take actions, and direct workflows based on error messages. If a tool presents an error, check for additional handling instruction in the configuration panel.

Add Admin ability to place the Alteryx Service (Engine) into Maintenance mode allowing current workflows to complete, but all new workflow processing moved into Queue to allow for server configuration and/or maintenance.

Currently, if I want to make a small configuration change (like a memory setting in the Runtime settings) I have to hunt for a quiet window or the lowest level of activity to kill the service (and the running jobs).

It would be helpful to flip a 'switch' and have all new jobs go into 'Queue' allowing for the change and service stop/restart ... then pick right back up with the queue in configured order. (execution time, priority level, etc...)

Hello Alteryx team, 

I would like to propose idea that was mentioned on the community but there is no solution either.

It was mentioned at https://community.alteryx.com/t5/Alteryx-Designer-Discussions/Data-Cleansing-tool-suddenly-stopped-w...

The issue is related to Qlik Analytics Samples and error that it is causing with wrong path error for default macros like eg.CountRecords.

Allow admins to configure an outage window(s) of a specified amount of time (say 5-6pm every sunday) for conducting admin activities. Specifically this outage window would block any scheduled jobs, drive any manual started jobs to queue, and also issue a popup on the gallery to notify users that it's during an outage window. 

When a user publishes and schedules a workflow on the gallery, they have the option to specify their time zone to ensure that the execution of the workflow occurs at the appropriate time. However, if the workflow invokes the DateTimeNow() function, the captured time is in UTC. If it is important for the end-user to have that time that is captured be in their local time zone, they will need to manually (either within the workflow or as a user input for an Analytic App) specify the offset from UTC.

Instead, there should be an Engine variable that captures the offset (or the time zone) that the workflow was executed from (or scheduled in), which can dynamically adjust the DateTimeNow() output appropriately.