Community Spring Cleaning week is here! Join your fellow Maveryx in digging through your old posts and marking comments on them as solved. Learn more here!

Alteryx Server Discussions

Find answers, ask questions, and share expertise about Alteryx Server.

What causes schedules to "Disable"?

Claje
14 - Magnetar

Hi,


For the second time since implementing 2018.3, I've had workflow schedules suddenly update to a Disabled status on the Gallery, without being changed in any way.  While it is pretty straightforward to re-enable these, it has caused us to miss a few scheduled runs.


Does anyone have any thoughts on what can cause a schedule to switch to a "Disabled" state?

23 REPLIES 23
Kethan_Patel
6 - Meteoroid

This is a know issue and it has been fixed in Version 2019.2.7.63499.

 

clipboard_image_1.png

 

 

davidhenington
10 - Fireball

This appears to be back with newest version. 2019.4.6.21113. 

 

Scheduled workflows flipping to disabled with no rhyme or reason on multiple artisans. 

davidhenington
10 - Fireball

Update: this appeared to have started occuring when one user shared several workflows to our internal "public" studio. 

 

Suddenly only the workflows that were shared retained their schedules. 

 

Very odd! 

thedr9wningman
8 - Asteroid

I've re-ticked that box about 100 times. In my environment, it is still shutting off the re-scheduled jobs within 5 minutes. And my customers are not happy about this. 

thedr9wningman
8 - Asteroid

I work in the same environment as @davidhenington and want to confirm that this is an issue. I have tried multiple means to test and fix this issue and the only fix I have that currently keeps my jobs scheduled is moving the scheduled workflows to the Public Gallery within our corporate instance of Alteryx Gallery. 

I hope this band-aid helps others in the future; it makes the public gallery a little polluted, and has a security problem in the sense that anyone can run your workflows, but I'm lucky enough that I have had minimal user-input in my scheduled workflows and they cannot choose where the outputs go (and therefore have access to data that they don't need access to). 

Bonus learning: I was able to turn off the 'download this workflow' option in each workflow's page on Gallery under its icon in Workflow Settings. 

thedr9wningman
8 - Asteroid

@MichaelF 
Question: When you say:

"😎 If credentials are expired, Scheduler will try to run a few times and then disable."

Which 'credentials' are you talking about? Windows credentials? Credentials to log into Gallery? Credentials for the workflow itself? 

This issue is plaguing me and I'm trying to get to the bottom of it, but I'm having a hard time figuring out what piece of the (very complex) puzzle needs fixing. 

Kethan_Patel
6 - Meteoroid

Can you add the user explicitly to the permission tab? 

 

That's the fix Support have provided in the past and it works.

wildflower
8 - Asteroid

@davidhenington Do you happen to have a workaround? We're on 2019.4.6. A public workflow in our studio has a schedule set up by an end user (an Artisan) outside of our studio and it decided to revert to disabled last Friday. Workflow and schedule hasn't been touched in 4 months. I'm in the Admin page and when I go to edit the schedule to re-enable it, I only have these options. This prompt is not true, it's a public workflow... No, Alteryx, I don't want to delete it.

wildflower_0-1581959244752.png

 

thedr9wningman
8 - Asteroid

Hi @wildflower 

I worked with @davidhenington when he was at the company we worked together on. He is, unfortunately, no longer with the company. I remain, though.

 

The public workflow option was our workaround. That is my current workaround for ensuring that the disable dialogue isn't happening. 

 

My best recommendation is to ensure that the workflow is indeed in the (local) public gallery. Any changes made to the permissions of the gallery association has, at least for me, resulted in the automatic disabling of the workflow. 

 

We have one colleague here who is able to share it to a new collection he created and those workflows are stable. The collection was built after the server was upgraded to 2019.4.6. I tried to mimic that behaviour and could not get the same results. For our environment, the only thing I can get to work is publishing the workflow to the public gallery. Its membership in collections or private studios has no apparent bearing on whether it is auto-disabled or not, as long as it is in the public gallery. As soon as I take it off public, it auto-disables. 

 

Although I hear you that the workflow/schedule hasn't been touched in 4 months (which frightens me), I still recommend re-upping the gallery membership for that workflow into the public gallery. I'm super curious as to the seemingly random behaviour of this particular bug. 

 

Best of luck. We seem to need it right now. This issue has been lingering a month or more and I have no hope or inkling that it will be fixed soon. 

 

wildflower
8 - Asteroid

Thank you for the suggestion, @thedr9wningman - making all of our ETL workflows public isn't an option for us as there are sprocs, SFTP, and email rendering we don't want the rest of the company to accidentally run. 

 

I did some digging and want to provide more detail on the error screenprint I posted: It's definitely a BUG with server 2019.4.6. I queried MongoDB and found the workflows that used to reside in one studio are now in another studio. That's the reason for the error, the workflows are no longer in the studio where the publishers are still members of. This then causes the schedules created in that studio to break (Disabled).  We create studios for departmental teams. I had moved one user no longer part of a team out of that team's studio into another studio - this user did not publish any workflows to the gallery however, all workflows in the original studio moved with that user during the Subscription edit. This is a huge inconvenience and we'll most likely have to make manual edits in our MongoDB.

 

Our workflows must remain private for security protocol. I could create collections as a workaround but would rather the bug be fixed! I've initiated a case with Support.

 

Screenprint mentioned: Error loading schedule.The workflow this schedule uses is no longer available to this user. Do you want to delete the schedule?