User Accounts

In some Curiosity applications, it might make sense for everybody that has a User account to be able to search for and view all of the data in it. Even in this simplest Access Management scenario, there will still be a distinction between:

  • Admin Users - Users that have full access to the system and are responsible for importing data, configuring how data is displayed and what options are presented in searches (amongst other things)

  • End Users - Users that limited access to functionality within the Curiosity system, focused on using the search facilities to locate items through text search, filtering, similarity, etc..

The difference between these types of User account come down to what task level permissions that they have. In this simplest example, the Admin Users have the System Administrator role assigned to them while the End Users do not.

For more complex scenarios, there are more granular roles that may be applied - for example, particular End Users may be given additional access such that they may explicitly manage abbreviations or synonyms.

Assigning permissions to particular Users is covered in the Users article, as is how you may manually create User accounts.

An alternative to manually creating User accounts is to integrate with an "External Login Provider" that offers Single Sign-On (SSO). Once configured, when Users log in via these third parties (eg. Google or Microsoft), a User account will be created in Curiosity that you may then set permissions for. For more information, see the External Login Providers articles in the Access Management section.

Node-level Permissions

As well as task level permissions, it is also possible to make specific nodes visible to or hidden from particular Users.

Instructions on how to apply such permissions are described in the Limiting node access to particular Users or Teams article (and some information about how these permissions are defined in the graph are further down this page).


For Curiosity applications with many Users, it may become too much work (not to mention error-prone) to have to set node-level permissions for individual Users. In these cases, groups of Users may be created—referred to as "Teams".

Permissions for individual nodes may then be restricted to particular Teams instead of (or as well as) Users. This is also covered in the Limiting node access to particular Users or Teams article.

Teams have the added benefit that when a new User account is created (either manually or via an SSO login), it may be added to the appropriate Team and they will immediately get access to all of the restricted nodes that they should.

The permissions schema

When a User or Team has access to a node that others do not, it is said that the User or Team Owns that node and that the node is OwnedBy that User or Team. If multiple Users and / or Teams have restricted access to a node then they are all described as owning that node.

These connections are represented by the system edge types _Owns and _OwnedBy.

The connections that describe a User's membership within a Team are similar and there are also system edges types used for these relationships: _MemberOf (going from the User to the Team) and _HasMember (going from the Team to the User).

To illustrate how a User (let's say Dan Roberts) may be considered to have access to a file (Document.docx) due to their membership in a particular Team (Dev Team), this is how the graph view would look:

If a node is to be visible to all Users of the system (whether that is because the node type is configured to be Visible to all or if the node type is configured such that User/Team-permissions may be applied but this particular node is configured to be for Public Access*) then there will be no owner for the node.

* (see Limiting node access to particular Users or Teams for more details on these options)

Did this answer your question?