Users

Dynamicweb Users is our built-in suite of features for handling everything related to registered user accounts – whether they’re backend accounts like an Administrator or Editor account, or frontend accounts belonging to a salesperson or a customer.

Like other areas of Dynamicweb, this area is accessed via the area menu (1) and consists of a tree (2) where you select a user group or feature to work with, and a content pane (3) where you view and work with the data (Figure 1.1).

User accounts can be created in several ways:

  • From backend using e.g. a the right-click context menu in the users tree
  • From frontend using a paragraph app:
  • As a part of an integration setup where user accounts are imported from an external system such as Dynamics D365 Business Central or Dynamics D365 Finance & Operations

A user account generally consists of:

  1. A user name
  2. A password
  3. A number of optional standard fields for storing additional information about a user account, e.g. address information, customer numbers, a profile image, etc.

There are three system user types in Dynamicweb – Administrator, Admin, and Default. The first two have backend access by default, the latter does not unless it’s been explicitly provided. It is also possible to create custom user types.

Users are typically organized in user groups – which at the most basic level are simply containers for users, but many other parts of the system – e.g. Email Marketing – also use user groups, for instance when selecting a set of recipients for a specific email marketing campaign or email flow. But the most important role for user groups is that they are used when setting up permissions – levels of access to the backend and the frontend.

Users can be quickly imported or exported to/from a user group using the import/export tool. On integrated solutions this is of course instead handles by the integration.

Permissions are rights given to users, as members of a specific user group or because they hold a system role such as Administrator.

Each permission level – Read, Edit, Create, Delete and All – corresponds to a specific level of access to a part of the backend and/or frontend, making it easy to implement e.g. role-based access control, restricting various roles to only the parts of the solution relevant for their particular tasks 

Permissions can be set by users with the All-permission for an area – by default this is Administrator users, but other user groups can be given All-permission to select parts of the backend, if appropriate. You can read more about permissions, system roles, and permission inheritance in the permissions-article.

Where the user group structure is relatively fixed, you can also do searches across user groups and use them in various places – e.g. to select recipients for an email.

Two different types of queries can be created:

  • Smart searches can return users based on dynamic criteria such as user information (Country, Name, etc.), audit information (creation date, last login, etc.), and user behaviour (pages visited, time spent on site, has received email X, etc.)
  • Repository queries can return users based on information in a user index

The choice between these two types of dynamic queries is largely based on the intended use:

  • Smart searches can be used to populate user groups with users, repositories queries cannot
  • Repository queries perform much better as the number of users scale
Figure 4.1 The Search node

As you can see, user accounts which do not belong to a user group are shown with a red background – and as elsewhere, users which are inactive or inaccessible to you are shown greyed out. You can right-click an orphaned user and select Add groups to add it to one or more groups.

Impersonation is a user-related feature which allows a user to act on behalf of other users – typically sales representatives and key account managers, who place orders on behalf of some of their accounts or a customer. This is useful in a number of B2B scenarios and also for troubleshooting purposes during development and testing.

There are two impersonation modes:

  • Full impersonation replaces the current user with the impersonated used for everything, including frontend permissions
  • Only Orders impersonation simply allows the impersonator to place orders on behalf of the impersonated user

Which mode is appropriate depends on the business case.

The General Data Protection Regulation (GDPR) was adopted in the European Union in April 2016, and became enforceable in May 25th 2018. This regulation is designed to provide EU citizens with better control over their personal data, and requires any company which stores and uses the personal data of EU citizens to take steps to protect that data and e.g. make it available for the user to download. Personal data is any information relating to a person who can be identified directly or indirectly, such as ”(...)a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.”

Furthermore, personal data may only be collected if a user consents to it. A consent is a ”freely given, specific, informed and unambiguous indication of the data subject’s wishes by which he or she, by a statement or by a clear affirmative action, signifies agreement to the processing of personal data relating to him or her.”

Consents must consist of clear, concise and granular positive opt-ins such as:

  • Consent to receive newsletters
  • Consent to using previous purchases to show personalized suggestions
  • Etc.

Or in other words; the user must be informed about precisely which data you want to use, why you are collecting it, and what you want to use it for, and must actively elect to give consent to that activity – a consent cannot be collected using e.g. pre-ticked boxes or other methods for default consent.

In Dynamicweb:

Bear in mind that you don’t have to use these tools to be GDPR compliant – consents collected via other sources (e.g. phone calls) – can simply be stored in a set of custom fields. The Data Processing app is simply a convenient tool for storing consents which are obtained using our system.

If you store email-consents in custom fields, you will have to uncheck these custom fields on unsubscribes – this can be done via the Dynamicweb users recipient provider settings.

Extranet is a paragraph app which can be used to:

  • Register new user accounts
  • Log existing users in
  • Publish account details
  • Allow users to edit their account details
  • List users and/or user groups in frontend

Some of these features have since been replaced by the ability of the query publisher app to publish users indexed in a user index – but it is still the go-to app for creating & logging in users in frontend.

External Authentication means logging in to the frontend or backend with external credentials – e.g. a Google, Facebook, or Azure AD account. Dynamicweb ships with several login providers for integrating with external authentication services, e.g.:

Each of these require you to set up or configure something on the other side – the non-Dynamicweb side – such as an app or a web service, which then provide you with the parameters for connecting to them from Dynamicweb.