As of Dynamicweb 9.4, you can switch from the permissions model you all know and love to a more granulated model which allows you to set permissions on (almost) everything using the same unified and flexible permissions model.

This is a major upgrade to the existing model, as it allows you to create specialized user groups and only give them access to the parts of the solution which they should have access to. 

To use the new permissions model, you must first enable it. Go to Settings > Control Panel > Users and check the use new permissions model checkbox (Figure 1.1). If you do not see the checkbox on a version after 9.4, contact your partner account manager to add the new model to your license.

Figure 1.1 Activating the new permissions model

Once the new permissions model has been enabled, you can right-click elements in the backend and click Permissions to access the permissions control dialog (Figure 1.2).

Figure 1.2 The permissions dialog

From this dialog, you can:

  • Set explicit permissions for a user group or system role
  • View permisssions inherited from a user group or system role

The permissions hierarchy and permissions levels are explained in the next section, and system roles are explained in the section after that.

The different permissions levels you can give a user group form a hierarchy, where each permission level includes or supercedes the previous levels. This means, that if a user has Delete permissions she also has Read, Edit, and Create permissions.

The exception is the None permission, which is hierarchically the highest level but does not include the previous permissions. Think of None as an explicit ban on viewing and interacting with content.

Permission level


Included permissions

Not set

No rights



Can access and view content/settings



Can edit existing content/settings



Can create new content/settings

Read, Edit


Can delete content/settings

Read, Edit, Create


Can set permissions

Read, Edit, Create, Delete





No rights

Overrides all other permissions

Permissions apply to both the frontend and the backend – so a user with an explicit None permission for a particular area or website is effectively banned from accessing that area or website in both frontend and backend. This is true even if a user is an Admin or an Administrator. The hierarchy reigns supreme.

In typical scenarios, you want to have different default permissions for the frontend and the backend of a website:

  • Users should have access to frontend content unless explicitly denied access
  • Users should not have access to the backend content unless explicitly allowed access

Enter system roles.

System roles exist to supply default permissions to users who are not members of a group for which explicit permissions have been set. This means different permission levels can be assigned to e.g. anonymous users (frontend) - Read - and Administrators - All.

By design, the following system roles and default permissions are used:

System Role

Default permission


Anonymous users (frontend)


You usually want anonymous visitors to have access to the frontend.

Authenticated users (frontend)


You also typically want logged-in users to have access to the frontend.

Authenticated users (backend)

Not set

Backend-users are not explicitly given any rights. This means that by default they see a blank page

Remember, Not set is the lowest permission level and any inherited permission overrides it.



Administrators are given All permissions by default, which means they can set permissions.

We do not support editing system roles and their default permissions, although all default permissions can be overridden by setting explicit rights for the system role. Instead, we recommend that you set default permissions at the user group level.

Banning yourself

The None permission is effectively a ban. If you set the permission for Authenticated users (backend) to None, you effectively ban all non-Angel accounts from accessing that area.

This includes your own account. So don’t do that...

An important concept to understand about permissions is inheritance. By design, all content under an element with permissions set inherits the permissions of that element unless a more explicit permission is set.

This means that if you set permissions on e.g. a page they are inherited by all subpages, all their subpages, and the full collection of paragraphs under those pages unless a more specific permission is set:

  • Page 1 (Delete)
    • Subpage 1 (inherits Delete)
    • Subpage 2 (None)
      • Subpage 1 (inherits None)
        • Subpage 1 (inherits None)
        • Subpage 2 (Read)
      • Subpage 2 (Read)
        • Subpage 1 (inherits Read)
    • Subpage 3 (inherits Delete)

Where pages can only be located in one place in the tree, things are a little different when it comes to products; a single product may be a member of more than one product/warehouse group. This has some implications for how permissions are inherited.

For example, Product 1 is a member og two groups – one of which is explicitly set to None permission:

  • Shop 1 (Delete)
    • Group 1 (inherits Delete)
      • Product 1 (inherits Delete)
    • Group 2 (None)
      • Product 1 (inherits None)

In these cases, the context determines which permission level is primary – so you can navigate to and access Product 1 through Shop 1 > Group 1, despite the None permission inherited from Group 2. In cases where the context is unknown – most notably in queries & searches – permissions are merged in the regular manner and None will supercede the Delete permission, which means Product 1 will not be available in search results.

If a user is a member of several groups with different explict permission levels for the same area, the highest permission level is used; Not set < Read < Edit < Create < Delete < All < None.

In general, permissions are inherited from accordion buttons to area trees, and from tree nodes to the content under the tree nodes - so permissions set on the Users area button are inherited by user groups and by the list of users in the group.

However, all systems have some idiosynchrasies which need to be taken into account – here are ours:

  • Settings: Permissions set on the area button ARE inherited to the nodes in the Settings tree – but (for technical reasons) not to the content under each tree node. This means that if you can see a setting you can change it – as a consequence, the minimum permission which grants access to the Settings tree is Edit.
  • Apps: Permissions on the Apps node are inherited to the apps located under it. These apps are also used elsewhere on the system, e.g. the Product Catalog app is used to show products in the backend as well as in frontend. So don’t set explicit None on the Apps area unless you want to deny the users access to the product catalog.

In general, these idiosynchrasises should prove to be no issue at all unless you grant people too much access from the beginning and then try to deny them using the None permission. We recommend that you don’t grant user groups a default permission but instead provide them explicitly with access to the areas they need to access.

Like system roles, regular user groups can have a default permission level which is used whenever no explicit permission level has been set for a user in the user group. 

It is set when creating or editing the user group settings (Figure 6.1):

Figure 6.1 User group permissions

Once a default permission is set for a group, the group permission will be listed as an inherited permission alongside the system role permissions when you set permissions (Figure 6.2).

Figure 6.2 Inherited default permissions

Please note, that the default permission is a fallback value - if you want to quickly configure permissions for the users in a particular group you should use the permissions matrix instead.

To make it easier – a lot easier – to set up permissions on a solution, you can use the permissions matrix to quickly set permissions for all users in a given user group.

Open the user group settings and click the Permissions button (Figure 7.1).

Figure 7.1 Launching the permissions matrix

This opens the permissions matrix dialog (Figure 7.2), which contains a list of select parts of the system for which permissions are typically set. 

Figure 7.2 The Permissions Matrix

The list is not exhaustive but does make many routine operations a lot more managable. Currently, the matrix allows you to set permissions on the following:

  • Areas
  • Websites
  • Settings tree nodes
  • Ecommerce tree nodes
  • PIM tree nodes
  • Shops & PIM Warehouses
  • Ecommerce languages
  • Ribbon bar tools for common products 
  • Ribbon bar tools for PIM products
  • Ribbon bar tools for Ecommerce products

At the technical level, this is simply a timesaving operation – it spares you from right-clicking on various buttons and nodes and explicitly setting permissions for this group. It overrides any default permission defined for the group (as you have now set specific permissions for the users in the user group).