The Expired Service Account
An Alteryx Server environment uses Windows authentication for users. Scheduled workflows run under a service account named svc-alteryx. The service account password is set to expire every 90 days per corporate policy. Last week, 40 scheduled workflows began failing at their scheduled times with authentication errors. The admin reset the service account password in Active Directory and updated it in the Alteryx System Settings, but the scheduled workflows still fail. Manual runs by logged-in users succeed. The admin confirms the service account can log in to the server interactively.
1. Why do the scheduled workflows still fail after the password was updated in System Settings?
Read the worked answer
Scheduled workflows in Alteryx Server run under the credentials configured for the Alteryx service and, depending on configuration, under stored credentials for the workflow owner or a Run As user. Updating the password in System Settings changes the service logon account, but it does not automatically update every place where the old password was cached. In particular, if workflows were saved with embedded credentials or if the Run As user for the schedules is the service account, those stored credentials still contain the old password. The service may also need to be restarted so that the new logon credentials take effect for the worker processes.
The admin should verify the Run As setting on the affected schedules, re-enter the service account password wherever it is stored for those schedules, and restart the Alteryx service after the System Settings change. Manual runs succeed because they execute under the logged-in user's credentials, which were never expired.
2. What long-term configuration change would prevent this class of outage?
Read the worked answer
The root cause is that a password with a 90-day rotation policy is being used as a long-lived credential for unattended scheduled execution. The durable fix is to decouple scheduled execution from an expiring interactive password. Options include using a managed service account or group managed service account whose password is rotated automatically by AD, or configuring the schedules to run under a dedicated Run As account whose credential rotation is coordinated with the Alteryx configuration. The admin should also document every location where the credential is stored (service logon, schedule Run As, stored data connections) so a rotation updates all of them in one procedure. Finally, monitoring should alert on scheduled authentication failures so the next rotation is caught before 40 workflows fail.