This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Our organization is currently experiencing a very annoying issue with scheduled workflows on the Alteryx server which we have not been able to resolve. So far support has not come up with a solution either, so I am now posting here in the community forum hoping that someone might have seen this issue before.
Short description of the issue: We are running anAlteryxServer with Gallery, which we use to schedule workflows. On a frequent basis - but with no apparent pattern - we see that all our scheduled workflows simultaneously goes from the "Active" state and into being "Disabled" (see image below). When we click "edit schedule" on the disabled workflows it shows this error in red text: "The workflow cannot be accessed. Request access or delete the schedule." The admin then have to re-enable all scheduled workflows manually by checking the "Enable this schedule" box.
As mentioned, we have not found any cause or pattern for this to happen - sometimes it happens within a week, sometimes a month.
Our setup and what we have tried: Alteryx server version: 2018.4.5.55178 Alteryx Designer version: 2018.4.3.54046
We have a handful of users (Artisans) who schedule workflows from their Alteryx Designer and onto our internal Alteryx Server Gallery. We use "built in authentication" which enables us to lookup users in our current AD and let them run workflows in their own user context (after they have supplied their AD credentials in the "Workflow credentials" admin section).
Authentication type, admin and default run mode are set as below:
In the "Workflow credentials" section, our users enter their AD credentials so they are stored in the system:
We have set "Require user credentials", so that users will have to enter their own AD user credentials when running/scheduling workflows:
In the "Workflows" section, workflows are scheduled and run in the users own context (we do not use "Run as a different user" in the server settings):
The scheduled workflows seem to run fine for quite a while (sometimes a few weeks, sometimes a month), but then at some point they all simultaneously change to the "Disabled" state. We have investigated and tried the following:
Checked if the server had crashed, been rebooted, patched or if the Alteryx Service had crashed.
Made sure it wasn't the users changing their AD password/credentials (which would also make their workflows change to "Disabled"). Since all workflows for all users go into Disabled simultaneously, this seems unlikely.
Checked if the credentials for the account running the AlteryxService was changed
Checked if the Private Studio all the workflows are added to belonged to a disabled user
Tried to add more ressource to the server (CPU and memory).
Upgraded Alteryx Designer and Server from a previous version
We have not been able to find any specific events in the server orAlteryxlogs that could point us in the right direction (but may not know what to look for). Getting logs has also been a bit challenging as it's impossible to say when the issue will happen.
If anyone has seen this issue before, or have any input for the troubleshooting I would be very happy to hear it!
Unfortunately not, I have created a new case with support, but no solution so far. It's interesting you experience the same issue and error message - do you run a similar setup as the one I have described (Gallery with built in Windows authentication etc)? I'd be happy to hear more about your experiences and what you have tried to solve it.
Yes - we too have similar setup, we are running into this issue almost every other week. one reason we are thinking can be with our daily backups - we are thinking to change this to weekly. Just to avoid unforeseen abrupt stopping of services
i am working with support (Case #00275997 ), may be you can pass this case # to your Alt engineer - so they can consolidate the efforts.
Hey - Not sure if this will work for everyone or not, but we just experienced the same issue. How we resolved the problem was to go back and re-add users to the permissions section. Our issue was three users reports ran successfully and did not become disabled while three others did not run and did become disabled. We added those users back under the permissions tab and so far the issue has been resolved. We are still searching trying to figure out why the users disappeared from the permissions section.