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.
Question The below question was originally asked in the Discussion boards and comes up somewhat frequently from Server users:
Where I'm left scratching my head is how to best set up Gallery, manage permissions, and manage schedules. In an ideal world, I guess I'd see it going like this:
Developers create workflows & upload to private gallery
Admin (me) updates connection strings and performs cursory review before moving it into a shared area. Developers should be prevented from doing this.
QA team reviews and gives signoff.
Admin (me) moves to a shared area (a collection?) and schedules the workflow as needed. Developers sho uld be prevented from doing this.
Is this approach feasible given the functionality of Gallery? For now, it seems somewhat all-or-nothing to me. If I make somebody an Artisan, it seems like they can publish things to the gallery, schedule workflows, etc. But I may be completely missing something here.
Also, I'm using Windows authentication and I don't see any way to add users to a Subscription. There's literally no button below the Artisans & Members boxes. How do I do this?
Answer The below answer was provided KoryC:
What you're wanting to do is very similar to what we see other customers looking to accomplish - essentially, better and more granular control over what users can do within given projects, and a promotion process of workflows. Today, our Gallery does indeed, as you mention, provide the artisan access as a sort of all or nothing type of deployment. So unfortunately, the level of access control you're looking for today is not yet available, but it is on our roadmap and something we are actively looking at for a future release - this is one of our top priorities.
So today, the best approach is indeed to make those developers artisans. Yes, this will enable them to make things public or share them even if they shouldn't, but there are still administrative capabilities, such as removal of workflows, that can help in case such accidents or activities occur.
And as for the user-to-studio management in Windows Auth mode - we're looking to get that button added for an upcoming release, and on top of that, taking a good look and building out some better and easier ways of managing users in Windows Auth mode in general, much in alignment with how we want to make user and gallery management easier in the future.
Let me know if this helps. I know it's not the ideal answer you'd want today, but we are looking to make some significant improvements here. I'd also greatly appreciate any time you may have to go over features like this and to get more direct feedback in the future too!
As far as your question regarding Windows Auth vs. Built-in - no, it's not required to use built-in for subscription artisans (though members don't make much sense in a Windows Auth environment). It is, however, trickier to manage, as you've discovered. The facilities for managing studios-to-users in Windows Auth are lacking at the moment, and it's an area we're looking to improve. Copying and editing the subscription key is indeed the only way. And yes, only one subscription per user - though this is another area we are looking at expanding upon in the future.
There is a button in v10.5 to add artisans to a studio, but not for members, which will likely ultimately go away, at least with Windows Authentication deployments.
For more information about Gallery Administration and setup, take a look at the following article. The link goes to the first of a four part article series:
Alteryx Gallery Administration
Receiving the error below when attempting to schedule a module?
“An error occurred in the scheduler. Server Error: 500 Server Error GetExpectedValue: Expected “Container” but got “Sid” Incorrect type requested 1 actual 4”
Post v10.5 release, your Alteryx Server and working environment must be of the same version in order to enjoy the upgrades of the release and still be able to commit scheduled workflows correctly. When the versions of your worker and server do not match, you’ll receive the error above. While our recommendation is to be using the most up to date release, you can always upgrade or revert your designer version either at our Downloads page (current version) or the Previous Releases webpage. To check on the version you’re using, you can navigate in the Designer to the Help >> About menu.