Alteryx have recently dropped the latest version (2019.2 at the time of writing) of their software, and within it have come a series of neat additions in both Designer and Server products, but something that has gone slightly under the radar, is some new permissioning functionality now available with collections, which, wait for it, now allows for cross-private studio collaboration (if you are an Alteryx Server Admin, I'm sure you know why this is a bug bear; but if not, I will outline the differences below anyway!).
If you prefer the 'official line' on release features, Alteryx have created a knowledge base article on managing collections in version 2019.2 which can be found here; but I must be honest, I felt the article didn't go into enough detail regarding the key change and how this could benefit server deployments, and hopefully that is something I can cover off in this post.
Working with Collections BEFORE Version 2019.2
Prior to Alteryx 2019.2 collections could be used by a user to categorise content within their private studio into projects.
These projects could then be shared with other private studios (and their own) via a basic permission system. Any user added would get a 'viewer' type permission, which would allow them to only RUN the content in that collection.
Certain users could be added as 'Collection Admins', which allowed them to update, publish and delete content within a collection, however, the collection admin role was limited to those only within that users private studio.
The image above highlights how I cannot add Martijn as a collection admin, as he sits in the TIL NL private studio, and not the TIL UK private studio, where I, the collection owner, exist.
This means collaboration between functional teams was near-on impossible (without a user having multiple accounts so they could sit in multiple private studios, or the administrator having to continually move people into different private studios (remembering the rule that users can only ever exist in a single private studio at one point in time)).
For example, if I were in a business where we had set up our private studios along functional boundaries (think IT, HR, Finance, Marketing, etc.), then an individual developer in HR could never collaborate on the same canvas as a developer in Finance; this essentially meant HR and Finance could never work on a joint Alteryx project :(
Working with Collections AFTER Version 2019.2
In 2019.2 Alteryx released an entirely new permissioning mechanism for sharing your content via collections, and it's bloody brilliant.
When sharing a collection to either a private studio, or user, individuals are now prompted with the following screen...
Even though I created the collection, and exist in the TIL UK private studio, I can now give the TIL NL (or Martijn individually) a whole host of responsibilities beyond just a viewer (though if you want them just as a viewer, then you simply select none of the permission options and hit save).
If Martijn is the individual in charge of managing the deployment of the workflows to the wider business, then I can give him the ability to manage users.
However if Martijn is a fellow developer, and we are collaborating on a joint venture project between TIL UK and TIL NL, then I can now give him permission to ADD and REMOVE assets from the collection; but perhaps most importantly allow him to UPDATE assets that I have published.
That's right, people from different private studios can now collaborate and work on the same canvas.
Let's just dive into how this UPDATE permission works.
So I've added TIL NL with all permissions for both assets and users.
Now I have published an asset that my private studio owns to this collection, which you can see in the image below 'TIL UK - Ben Moss'.
The purpose of this workflow is to create a calendar event when an individual commits to writing a blog; I want Martijn and his team to be able to edit the workflow so they can include their teams email addresses so they too can have calendar invites for their blog commitments.
In order designer, I am now acting as Martijn; I have logged into the server and am connecting to the worklow in order to edit.
Now the above was always possible, even prior to version 2019.2 my users could connect to workflows/applications/macros that had been shared with them via a collection (providing the 'allow others to download workflow' option had been checked).
The difference comes when you go to save any edits you make.
Pre-version 2019.2, users would get a notification on the publishing window, indicating that their private studio did not own the content, and therefor should they wish to publish, they would be making a copy in their own private studio.
In fact, if a user DOES NOT have update permission in the latest version of Alteryx Server, they will also get this experience.
However, in 2019.2 or newer, if the user DOES have the update permission, then they will get the following experience, with the location set to the collection with which the workflow shared belongs, and they get no warning message about creating a copy.
Once we have published, by looking at the revision history for the workflow we can see that Martijns edits have been made to the workflow.
BINGO!
So how can I structure my Alteryx Server now?
Well, historically we have advised our customers to align private studios with their business divisions/functions, with one of the main reasons being that there was no way of sharing ownership of a workflow unless individuals were in the same private studio.
This new functionality, of collaborating via collections rather than private studios means, that we can now suggest to our clients that each individual user can have and exist within their own private studio; this can be beneficial for a number of reasons.
- It can be easier to manage (see disadvantage below as to the keyword 'can be'); when a user is added to Alteryx Server, by default, they are added into a Private Studio of their own. Historically an admin has had to then move you into the correct Private Studio.
- No more spamming your colleagues. When working in Alteryx people like to test workflows, and to test how a workflow performed on the Server environment, users had to publish to the server. As soon as they do this, the test workflow becomes visible to everyone, spamming the private studio; and when your peers aren't good at cleaning up their sh*t, this gets messy, quickly. If users have exist in their own Private Studio, it's only themselves that have to put up with their spam.
- Based on some of the demos we have seen at conferences of the new server product that Alteryx are building, this kind of environment would seem to migrate a bit nicer than groups and private studios.
However; a lot of the permissioning mechanisms are based around Private Studios, for example data connections, with each individual having their own private studio, administrating this could become painful as each unique user would essentially have to be added rather than the group of users in one hit via a private studio.
Another negative would be moving your users into this new structure; at present as private studios own content, if a user were to leave and be placed in their own private studio, the user would loose all of their content and schedules and therefor have to republish and set everything up.
To summerize, this new functionality is extremely useful and finally allows for collaborative working between business units without too much of a headache, and it may (but is still beneficial if you don't), effect they way you wish to structure your Alteryx Server environment.
Ben