Alteryx Server Admin common mistakes
Alteryx Server Admin · Understand the traps and how to avoid them.
Assuming the Controller node also runs the Worker process by default in a multi-machine deployment.
Candidates confuse the all-in-one default install with a distributed setup; they forget that the Controller and Worker roles can be separated and that the Worker service must be installed and configured on each worker node.
What to do instead
Review the Alteryx Server architecture: the Controller runs the AlteryxService and manages the queue; Workers run the AlteryxEngine and execute workflows. In a multi-node setup, the Controller typically does not process workflows unless explicitly configured as a worker. Verify service roles in Alteryx System Settings.
Believing that changing the Run As user for the AlteryxService can be done solely through the Windows Services console without updating Alteryx System Settings.
Candidates think the service account is only a Windows service property, but Alteryx stores the service account in its configuration and uses it for permissions to the MongoDB, logs, and temp directories.
What to do instead
Use Alteryx System Settings to change the service account, which updates the service configuration and grants required permissions. After changing, restart the service and verify the MongoDB connection and worker registration.
Configuring Windows Authentication for the Alteryx Gallery but forgetting to set up the required IIS authentication providers and disable anonymous access.
Candidates focus on the Alteryx authentication settings and overlook that the Gallery runs in IIS, where authentication must be configured at the website level.
What to do instead
In IIS Manager, for the Alteryx Gallery site, enable Windows Authentication and disable Anonymous Authentication. Also ensure the Alteryx Service account has the necessary permissions and that the authentication type is set to Windows in Alteryx System Settings.
Scheduling a workflow to run as the user who created the schedule without ensuring that user has the necessary permissions to access the required data connections and files.
Candidates assume the schedule runs under the service account or that permissions are inherited from the workflow owner, but by default scheduled workflows run under the credentials of the user who created the schedule (or the Run As user if configured).
What to do instead
Verify that the scheduling user has permissions to all data sources, data connections, and credentials used by the workflow. Alternatively, configure the schedule to run with a specific Run As user that has the required access.
Granting users 'Curator' or 'Artisan' permissions without understanding the difference between asset-level permissions and collection-level permissions.
Candidates conflate the ability to manage collections with the ability to manage individual workflows and schedules; they may give broad permissions that allow unintended access.
What to do instead
Review the permission model: Curators can create and manage collections and assign permissions; Artisans can create workflows and schedules but have limited collection management. Assign permissions based on the principle of least privilege, using collections to share content.
Ignoring the MongoDB logs when troubleshooting workflow failures, focusing only on the Alteryx Engine logs.
Candidates often check the AlteryxService logs and workflow results but forget that the Gallery and scheduling metadata are stored in MongoDB, and connection issues or authentication failures there can cause scheduling or UI problems.
What to do instead
When troubleshooting, check the MongoDB logs (default location: C:\ProgramData\Alteryx\MongoDB\log) and verify the MongoDB service is running. Also check the AlteryxService log for connection errors to MongoDB.
Backing up only the MongoDB database and not the Alteryx configuration files, logs, and custom components.
Candidates think the MongoDB contains all necessary data, but a full recovery requires the Alteryx System Settings, the RuntimeSettings.xml, the AlteryxService.exe.config, and any custom macros or connectors stored outside the database.
What to do instead
Follow Alteryx backup best practices: back up the MongoDB (using mongodump or the Alteryx backup utility), the Alteryx configuration files (typically in C:\ProgramData\Alteryx), and any custom components. Test restoration periodically.
Assuming that a data connection created with a 'User' credential type is available to all users and schedules.
Candidates confuse the credential types: 'User' credentials are specific to the user who created them and are not shared; 'Service' credentials are available to all users who have permission to the connection.
What to do instead
When creating a data connection, choose the appropriate credential type: use 'Service' credentials for connections that need to be shared across users and schedules. Ensure that users have permission to the connection and that the credentials are valid.
During an upgrade, skipping the pre-upgrade steps such as backing up the database and verifying system requirements, leading to a failed upgrade.
Candidates underestimate the importance of preparation and assume the installer will handle everything. They may not check for compatible versions of MongoDB, Windows updates, or disk space.
What to do instead
Always perform a full backup before upgrading. Review the upgrade guide for the specific version, ensure the system meets requirements, and run the Alteryx upgrade checklist. Test the upgrade in a non-production environment first.
Configuring a worker to use a different MongoDB instance than the Controller, causing workflow execution failures.
Candidates may inadvertently point a worker to a separate MongoDB during installation or configuration, not realizing that all nodes must connect to the same MongoDB for the Gallery and queue to function.
What to do instead
In Alteryx System Settings on each worker, verify that the MongoDB connection string points to the Controller's MongoDB instance. The worker should use the same MongoDB as the Controller. Check the worker's AlteryxService log for connection errors.