The Connection That Works for One, Fails for All
A team publishes a workflow that reads from a SQL Server database using a data connection configured as a system connection with embedded credentials. The workflow runs successfully when the owner runs it manually. When it is scheduled, it fails with a login error. A second workflow that uses a user-level connection owned by a different user also fails on schedule. The database team confirms the service account has read access to the database and that the SQL Server is reachable from the workers. The admin checks that the Alteryx service is running on all workers.
1. What is the likely cause of the scheduled login failures for the system connection?
Read the worked answer
A system connection with embedded credentials should be available to scheduled runs, so a login failure suggests the credentials stored in the connection are not what the database expects, or the connection is not being resolved at run time. Common causes: the embedded password was changed on the database side but not updated in the connection; the connection was created as a user connection despite being described as system-level, so it is only available to its owner and not to the service account running the schedule; or the workflow was published with the connection embedded rather than referenced, so it uses stale credentials. The admin should open the connection in System Settings, verify it is a system connection, re-enter and test the credentials, and confirm the scheduled workflow references the connection by name rather than carrying an embedded copy.
2. Why does the second workflow, using another user's connection, fail, and what is the general rule?
Read the worked answer
A user-level connection is scoped to its owner. When the workflow is scheduled, it runs under the service account or the configured Run As user, not under the connection's owner, so the user-level connection is not visible and the workflow cannot authenticate. The general rule is that scheduled and shared workflows must use system-level connections (or connections explicitly shared with the running identity), because user-level connections do not travel with the schedule. The fix is to recreate the needed connection as a system connection with credentials the service account can use, or to share the connection appropriately, then update the workflow to reference it.