Engine Works

Under the hood of Alteryx: tips, tricks and how-tos.

Districts or Collections?


Within the Server, there are two main sharing spaces: the districts and the collections.

Districts are public spaces; each person having access to the Server will be able to access it and consume its content. They are ideal for applications or services that do not require rights or permissions.

Collections are shared spaces with permissions. Only authorized users will have access to one or more collections. They are ideal for work groups that share a common goal but are not public (e.g., controlling, human resources, project x or y...)


Organizing the Districts


Here is an example of how districts can be organized:




The idea is to group workflows by category (here: Training and Self Service). Imagine the services you want to offer and organize them according to their roles (for example, My HR services, with applications listing your HR contacts within your company or a general services district with the calendar of holidays or upcoming events... The possibilities are limitless).

My training district allows employees to find challenges to train themselves on new issues and continue to learn. It can also be used as a base for onboarding on Alteryx for new users.




Here is another example of a district that is similar to a general service district:




This district contains different services for my users. Here are some examples:

  • A calendar of working days, holidays, weekends...
  • A license ordering service
  • A documentation workflow
  • An application to perform non-regression tests

Any user in your company could have access to these services whether he is an Alteryx Designer user or not; a simple internet browser is enough.


Organizing the Collections


We recommend you create collections that reflect your team’s organization structure.




For example, we can create as many collections as there are teams (Finance, HR, Marketing, Risk, ...). This approach allows you to structure and secure the content that each team will produce.






For the system to be sustainable (and understandable), it is important to respect some principles:

  • Avoid user level permissions and used whenever possible group level permissions
  • The same permission structure applies to all groups (with as few exceptions as possible)


Creating user groups


For each collection, we create three user groups, so we can handle different responsibilities for each user groups:


  • an admin group
  • an artisan group
  • a member group


To facilitate reading and future additions of users, we use the following nomenclature: [Name of collections] - [Role]


And, of course, we assign the corresponding role to the created group:





All users have the default role (to be defined by the administrator, Viewer is a good role to allow any user to have access to Districts), and it is the assignment to a group that will define its role and scope of action in the collections.




Setting up the security matrix


Now that the groups exist, we can set up our security matrix on the collections. On each collection, we will manually assign the groups (example: Collection Name – Member) with their permissions over the collections (see the picture below for an example):


  • Consumers will be able to simply consume the content of their group
  • Artisans will also be able to add and delete content (note: more detailed management is possible by adding a group by permissions - see below)
  • Administrators can add and remove users to the group (this role is optional as the matrix should not move over time)


Example of a matrix on the Marketing collection:




It is now extremely easy to add users with the right level of permissions.

Example: "I have a new user who will create workflows for the HR team and who will have to consume workflows from the risk team."


For this example, I just need to add the new user to the following groups:

  • HR - Artisans
  • Risk - Member


The Groups-Collections Axis is fundamental in the organization of the server.




The organization in place can cover most of the needs. But what if a new working group is needed (for example, a special project that requires advanced collaboration between Finance and Risk. This project may even be temporary).

To deal with these situations, without questioning the previous organization, we can create a collection dedicated to this project and thus three user groups for this collection (as before).


Thus each specific project will have its own dedicated space, and the group-collection axis remains unchanged.


Mechanism for controlling rights


To make sure that the matrix representing the groups - collections axis is up to date, I can use a monitoring application for administrators. In my case, I have created a report to check the correct application of this jurisdiction. It allows me to validate this matrix at a glance.





It is simply an Alteryx workflow that will check in the MongoDB database the applied parameters. It would be just as easy to set up alerts to check that the collection name is consistent with the group name or that each permission is consistent with the role contained in the group name. These alerts could be sent to the administrators to supervise the good compliance of the system.




The implementation of a secure, durable but flexible, and easily maintainable organization is very simple. The means of control are numerous and can be automated.


Your users can now benefit from numerous services thanks to the Districts and collaborate in their respective Collections to automate their analytical processes in complete security.