User Rights Management

This section contains a short guide on user rights management. PoolParty utilizes user roles to control permissions and user groups to control access.


Only a PoolPartySuperAdmin can access the User Administration. They create and manage users and user groups.

In PoolParty you can manage user access and permissions easily after you consider the following aspects:

  • User Roles: they provide permissions on a granular level and are predefined.

  • User Groups: they provide access for users to projects, ontologies and custom schemes.

  • By combining the roles and groups, you can define user permissions in an individual access model. See the example below.

User Roles and Permissions

User roles in PoolParty are predefined sets of permissions. Permissions in PoolParty are based on actions and functions a user can execute in PoolParty. They are separated into two permission types:

  • Server Permissions are all rights a user needs to execute actions on the server level, such as creating or deleting projects or creating snapshots.

  • Project Permissions are all rights a user needs to execute actions on the project level, such as creating or deleting concepts, create corpora or link data.

Additionally, you can grant project-dependent user roles, which differ for a given user from his global permissions on that PoolParty instance.

Details on project-dependent user roles and settings find here: Define a Project Specific User Role for a User

User Groups

In PoolParty you can define user groups. They work as a container for projects, ontologies and custom schemes. Using groups, you can grant rights to users for the respective projects, ontologies and custom schemes by assigning the corresponding group to them.

The only default group predefined on any PoolParty instance is the group Public.

The Public group has to be assigned to projects, ontologies and custom schemes if you want to make data publicly available. This group cannot be deleted.

The following features are provided when assigning the Public group:


Let's assume you have two projects, called 'All about Cocktails' and 'Wine & Cheese Recommender'. And for the cocktails project, there is also an ontology and custom scheme available.

  • Now you want to have one person (Admin) that sets up those projects and the ontology and scheme.

  • One person that should be able to manage the ontology (Ontologist). And two people who work on the respective projects only having access to one of them (CocktailsEditor, WineCheeseEditor).

  • Also, there should be a read-only user able to access both projects (Viewer).

To facilitate this scenario we need three user groups to grant access (CocktailsGroup, WineCheeseGroup, CocktailsOntologyGroup).

The diagram below shows the different users with their groups and roles and the projects and ontologies/schemes with the necessary groups.



Details about the User Groups and User Roles find here:

PoolParty Academy Tutorial

(Duration: 16m:59s)