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. 

The new permissions model is currently implemented for:

  • Menu buttons (Home, Content, Files, Users, Ecommerce, Marketing, PIM, Apps, Settings)
  • All trees nodes (Content, Files, Users, Ecommerce, PIM, Marketing, Settings)
  • Website settings
  • Apps (defaults to Delete for Authenticated users)
  • Settings:
    • Ecommerce languages

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 placed in a group for which explicit permissions have been set. This means different permission levels can be assigned to e.g. anonymous frontend users (Read), and backend administrators (All).

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

System Role

Default permission


Anonymous users (frontend)


You typically 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 permission by default. This means that by default, they see a blank page.



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 a user group level.

Banning yourself

Please note, that 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 particular page, they are inherited by all subpages under it, 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; an All permission overrides a Read permission, and a None permission overrides an All permission.

Like system roles, regular user groups can have a default permission level. It is used whenever no explicit permission level has been set for the users in the user group, and is set when creating or editing the user group settings (Figure 5.1):

Figure 5.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 setting permissions ({figurere}).

Figure 5.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 6.1).

Figure 6.1 Launching the permissions matrix

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

Figure 6.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 (menu buttons)
  • Websites
  • Settings tree nodes
  • Ecommerce tree nodes
  • Shops & Warehouses
  • Ecommerce languages

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).