Managing complex dataset and property permissions (RBAC)

Learn how to use Role Based Attribute Control by following our tutorial videos: RBAC (part 1) and RBAC (part 2).

An individual (via their role) must have at least view: permissions to access the dataset at all, then any property level permissions will override the dataset permissions at property-specific level,

Permissions: key concepts (troubleshooting)

  • No matter what other roles (permission groups) a user has been given in the ‘Users’ dataset (e.g. hr, superAdmin), they must have at least ‘user’ or ‘admin’ – otherwise they will not be able to access the Workspace
  • Users always need to be given explicit permissions to access datasets which they do not own i.e. Admin roles can always access all datasets; the owner/creator of a dataset can always access that; anyone else who requires access needs explicit permission to be able to access a specific dataset
  • Where lookup datasets are used - for validation, for providing custom colours etc., users need to be able to view lookup datasets: and in that sense lookups are "just another dataset" and will need permissions set, typically view: for non-Admins
  • In practice, some people will  be assigned to two or more roles (permission groups) which have different access level to the same dataset (or property), in which case the highest permission type available will apply to the individuals concerned
  • Each dataset may have only one tag of each type, although a permission type can be applied to multiple roles e.g.
  • Note that when setting Apply Tag (see screenshot at the end of the section) a different permission type must be set on a different line, but once saved each permission type will appear on the same line separated by ; i.e. the above example will display as
  • Multiple tags will not operate correctly when applied to one dataset e.g.


Tag Types and Application


basic permissions setting workflow

There are a range of tags available to customise the behaviour of datasets and properties:

In a basic example, if the dataset permission is set as edit:user and the named property is hidden, then the property will be hidden regardless of the 'edit' permission for anyone with the role 'user'.

There are only two exceptions to that example:

  • if the individual concerned has admin-level rights via the Users table
  • property tagging is enabled which always overrides generic property-level security: in the example at the end of this article, the role hrsecure would have edit permissions on the property even though it is set to 'hidden'











Listed roles can view the dataset only





Listed roles can update cell values only i.e. they have to work within the existing structure both in terms of nodes (cannot add or remove nodes) and properties





Listed roles can update (add/remove) nodes and associated cell values but not properties i.e. they can impact the data values generally but not the data structure





Listed roles can edit nodes, cells and properties i.e. impact both the data values generally and the data structure





Put the dataset in the Favourites tab for all users





Flag a dataset outside the Lookups tab as a lookup





Allow a dataset to be copied from the home screen





Automatically applied by OrgVue to surveys

At dataset level, the owner or Admin can set the level of Users' access to a dataset:


RBAC can be implemented at property level within a dataset

  • To limit a user’s access to dataset properties based on role, use the property ‘Security’ options
  • Note: setting a property to ‘Hidden’ will mean that standard users cannot colour by it or use it in any expressions.






Dataset/ property can be accessed and edited by anyone tagged as “edit:….”

Update only

Cell values can be updated but the structure (e.g. node hierarchy, property settings) cannot

View only Can be seen but not altered in any way
Hidden Cannot be seen by anyone other than admins and the dataset owner


OrgVue is cautious by default


These are key rules to help you understand how RBAC works between datasets and properties

  • ‘Hidden’/‘Private’ overrules other permissions, i.e., a private dataset is always hidden - a hidden property in a editable dataset is still hidden
  • For non-hidden properties, setting a dataset to ‘View’ overrides any property-level security
  • For non-private datasets, setting a property to ‘View only' or ‘Update only' will restrict access.

The following is an overview of the interaction between dataset and property level permissions:

More granular property permissions are available beyond Security using tags

It is also possible to use tags for specific properties, and the syntax is identical to that set at dataset level i.e. view,edit rights are applied to those roles configured in the User table.

In this way, it is possible to override the per-property Security settings to apply to certain users: grouped by role

In the example below, the Security setting for the property Pension is set to Hidden.  This means that all those individuals with access to the dataset will not see the property or its values based on the Security setting, however those users with the role 'hrsecure' as enabled in the User table will be able to view and edit this property.


Access Tag syntax example


(none set)

Read only

view: hrgeneral
Update only update:hranalyst
Edit edit:hrsecure







Have more questions? Submit a request