Settings

This section describes how to work with accounts (tenants), users within accounts, customization of accounts, and how to use the access management system of niotix. All can be done through the menu-item “settings”.

Accounts

An account represents an organization (e.g. a company, a subsidiary, a department, a city). For each account, you can customize connectors, user interface, etc. Like in a real organization, each account has a group of users. Depending on your user rights, you have permission to view and edit accounts and users.

When opening the “Account Mgmt” site, you see the hierarchy of accounts on the left [1] similar to the digital twins. Accounts can have sub-accounts. Depending on your user rights, you can see more or less elements of this hierarchy. You can add a new account by clicking on the “+ add new”-button. Otherwise, you can also select an existing account from the hierarchy. In both cases, you can see the details of the account on the right.

The box with the account details on the right is split into three tabs [2]:

  • Accounts: Configure the settings for the selected/new tenant.
  • Users: Administrate the users for this tenant.
  • API Keys: Administrate API keys for 3rd party applications

Tab ‘Account’

For each account, you can set a description to provide your colleagues and other users more details about the tenant.

Domain Mapping

In the domain mapping, you can add custom domains (URLs) for this account, which are set up by DIGIMONDO or your system administrator. A custom domain gives you the possibility to customize the default user interface right from the login-screen on. After adding a custom domain, you can configure your customization such as logo, colors etc. under “Account Mgmt > System Settings".

There are two cases to set up a custom domain:

  • For DIGIMONDO SaaS customers: Please contact your account manager at DIGIMONDO to set up a custom domain
  • For On-Premise customers: Please contact your system administrator to set up a custom domain

To add a new domain, put the URL into the textbox and click on the “+” symbol. You can add more than one domain.

Email Server Settings

Here you can set up a custom system email which is used to send out system emails for this account. System emails are e.g. the welcome email for new users or the email users receive when they reset their password.

User Password Policy

With the user password policy, you define the rules which users need to follow when they change their password. For the highest level of security, activate all checkboxes (“upper- and lower-case”, “numbers” and “special characters”) and define a minimum-length of at least 8 characters.

User properties

You can define custom user properties for your accounts. They are used to add additional information for organizational purposes to each account, e.g. telephone numbers, the corresponding department or the employee role.

To add custom user properties, write your individual attribute name in the “Attribute Key” field. In the user profile, you can add the corresponding individual value for each user. To add more fields click on the “+”-button, to remove fields click on the “trashbin”-button.

Detailed information about different accounts

According to your user rights, you can view the “Detailed information” field, which contains current data about the account, such as update dates, account ID, hierarchy level, number of twins, and number of twins in sub-accounts.

OAuth2 Configurations

You can define custom OAuth2 Clients (Instances) for your account. This enables your users to login using OAuth2 providers of your choice.

Available clients will be displayed to users on the login page.

New clients are created by clicking on the “+” button in the “OAuth Clients” section. You can add a name and logo for your Oauth2 provider. The configuration for the client is specified in the code block as a JSON object.

Clients can be saved and edited by clicking on “validate & save", and deleted by clicking on the “trashbin”-button.

Configuration

In order to allow successful authentication against an OAuth2 provider, a valid JSON object is required. When you click on “validate & save", you will receive either a success message, showing your configuration is valid, or an error message, showing what properties are missing or invalid.

When you create a new client, a JSON object with all necessary fields will be created automatically for you to fill out:

  • client_id: The ID of the service. May be called tenantId, or appId in some OAuth services.
  • client_secret: Client Secret provided in your OAuth service.
  • auth_uri: The authorization server endpoint URI.
  • token_uri: The token server endpoint URI.
  • scope: Defines the limit of the access to the user’s account. For niotix’ purposes, only access to the user’s email is required.
  • user_info_uri: The user server endpoint URI. This must always return a JSON object, containing the user’s email. ex.: { "email": "user@company.com" }
  • redirect_uri: Determines where the API server redirects the user after the user completes the authorization flow. The required route for niotix is normally https://api.<<your_niotix_domain>>/api/v1/oauth2/callback

You may configure as many clients per account and domain as you wish. Only one instance of a client needs to be configured, and it will be available to all sub-accounts and users, logging in at the specified niotix domain.

Once your client configuration is validated and saved, all users logging in from the Account’s domain URIs (see Domain Mapping), will be able to log into niotix using the specified OAuth2 provider.

If you wish to share a niotix URI, which makes only specific clients available, you can do so using the oauthClient query parameter with your clients’ client_ids: https://<<your_niotix_domain>>#/login?oauthClient=<<client_id1>>,<<client_id2>>

Currently, a user needs to be created in niotix first, before they are able to log in, using OAuth2.

Example for Google: { "scope": "https://www.googleapis.com/auth/userinfo.email", "auth_uri": "https://accounts.google.com/o/oauth2/auth", "client_id": "12837123862-kshfd7frkker7fdskdf.apps.googleusercontent.com", "token_uri": "https://oauth2.googleapis.com/token", "domain_uris": [
"niota.io" ],
"redirect_uri": "https://api.niota.io/api/v1/oauth2/callback", "client_secret": "skdfsd-dgsfssfkjshv7QwBI97P3P8", "user_info_uri": "https://www.googleapis.com/oauth2/v1/userinfo" }

Tab ‘Users’

In the users-tab, you can see all of the users for the selected organization as well as all of its sub-organizations.

Single users can be added by using the “add new”-button. If you need to create many users at once, you can use the “import”-button.

With the search bar, you can search for a certain user in the list [1]. Use the “trashbin”-button to delete the corresponding user or click on the “paper & pen”-button to edit [2]. Depending on your user rights, you can impersonate users by clicking on the “impersonation"-button. To quickly see what roles are assigned to a user, click on the user’s line and the roles appear in a drop-down menu [3].

Impersonate user

If you click on the above mentioned “impersonation” button, you temporarily imitate this user. You have the same views and permissions as the selected user, which is useful to give support to your users.

Impersonation is indicated on the top bar with a red box. To leave the impersonation mode, click on the “return” icon in the red box.

Edit user

If you click on “edit” (see [2] in picture above), you can edit the selected user:

  • First name: the user’s first name
  • Last name: the user’s last name
  • Email address: The user’s email address – this must be a valid email because the invitation to niotix will be send to this email address.
  • Active: With this box you can decide if the user account is activated or not. If this checkbox is deactivated, the new user cannot log into niotix.
  • User properties: Add the values for your custom properties. These information are just for your personal/organizational usage and are not used by the system.

Permissions

In the permissions section, you can assign the role (and by this access permissions) of the user. niotix provides a fine-granular possibility to define access rights. All permissions are referring to a scope within the system.

A scope is a group of objects in niotix, which is independent from the account. It groups accounts and especially digital twins. By this, administrators can define different rights per user and digital twins, e.g. a user can have read-only rights for one digital twin but editing-rights for another.

In this section, you can search for certain scopes [1], click on the scope to see what roles are assigned for this user in this scope [2] or add a new permission [3].

Add new permission for a user in a scope

To add a new role to the user, click on the “add new” button. In the pop-up menu, at first select the corresponding scope (digital twin) [1].

Next, you can select the roles you want to assign to the user for the selected scope [2]. From the dropdown list, you can select as many roles as you want. To save your selection, click on the “save”-button. You can cancel with the “x”-button.

A role is a collection of fine-granular rules, which can be set up in the “role editor”. Thus, the provided roles can be customized for each account and might differ from the screenshot below. To learn more about the standard-roles and their permissions and how to customize your roles, have a look in the section “role editor” below.

Add new user

By clicking on the “add new” button in the users overview, you can add a new user to the selected account. This works similar to editing a user as mentioned above, except for the initial selection of a scope and the possibility to define a default password:

  • Root permission scope: Select the root scope, the digital twin or sub-twin, where this users belongs. After setting this value, the section for a fine-granular definition of scopes ("access scope") will appear automatically (see section “access scope” below).
  • Password: The password of the new user – niotix automatically proposes a password.

IMPORTANT: The proposed password is only shown once here! As soon as you save the account, there is - for security reasons - no possibility to look it up again. It is important to write it down if you need it – otherwise users can define a custom password with the invitation email or by resetting their password on the login page.

Permissions

To start the configuration of permissions for the new user, select the root permission scope for which you want to set the permissions. Adding permissions works similar as when editing accounts, see above for more information.

Import and add many users

To bulk-import many users, select the “import”-button from the account management view. In the textfield, you can copy and paste the list of users (one user per line) according to following template:

Firstname;Lastname;Email;Username;{ "Test":"value", "sampleKey":"value" }

In the textbox below the textfield, you can select the root scope as well as the initial password for all users.

After selecting the root scope, you can fine-tune your permissions as described above for single-adding new users.

Tab ‘API Keys’

In the tab “API Keys", you can set up API keys used by 3rd party applications to access the niotix API. In niotix, you can define custom call-limits, expiration times and concrete permission for each key.

Edit existing API-Key

To edit an existing API-key, click on the pen & paper-icon in each row:

  • Title: The name of the new API-key
  • API call limit/min: Set the maximum number of calls per minute for the niotix XAPI and the Iot Data Hub niota 1.x API.
  • Active: Activated by default. Deactivate if this key should not be usable anymore.
  • Access Scopes: Adding permissions for the new API key works similar to adding new users. You first have to select the scope and then can assign roles. See chapter “add new user” above for more information.

Add new API-Key

By clicking on the “add new” button in the API-key overview, you can add a new API-keys to the selected account. This works similar to editing an API-key as mentioned above.

User Profile

With the user settings, you can customize your account. In comparison to the selection of the language and color scheme with the “gearwheel”-button on the top right, these settings are permanently saved and independent from the user’s local browser.

You can change your first and last name as well as update your email address. You can also change your password and set up two-factor-authentication.

ATTENTION: The email-address is used for logging in and resetting your password - so ensure that this is always a valid address you have access to.

Activate Two-Factor-Authentication

When you activate the Two-Factor-Authentication with the switch, a new popup appears to scan the QR-code with your authenticator-app and type in the 6-digit-code to confirm the process. We recommend to use the Google Authenticator App for your smartphone ( Link App Store / Link Play Store). Alternatively, you can also use the Microsoft Authenticator app. Once the initial authentication is successful, 10 more recovery codes will appear in the next pop-up window. You should keep these in a safe place and they can be used once in case you do not have access to the Authenticator app.

IMPORTANT: Never share your recovery codes and keep them in a secured place. In combination with your password, others can log in to your account with the recovery codes.

From now on, you will be asked for the 6-digit authentication code in addition to your username and password when logging in. The 6-digit code is also required to deactivate two-factor authentication.

System

In this section, you can customize the interface for the users of your accounts (tenants).

Except for the email-templates, all customizations require a custom domain at “Accounts > Domain Mapping” (see above).

ATTENTION: Customizations of the UI (e.g. custom wallpaper, logos and colours) are controlled by the domain the user is using and not by the account to which a user belongs! Please ensure that you give your users and customers the right URL to access the system to see the customizations.

To start the customization, you first need to select an account in the field “account selection” [1] at the top of the page. Depending on the domain settings for the selected account, you can see different sections:

Default & page settings

This is only accessible if a domain is set for this account. This section allows you to customize the default language and color mode for new accounts.

  • Color mode: Select if users use by default the light or dark mode of the user interface [2]. Users can change this setting for their browser via the “gearwheel” button on the top right corner.
  • Language: Select the default language [3]. Users can change this setting for their browser via the “gearwheel” button on the top right corner.
  • Drawer icon link: Select where a click on the icon on the top-left corner leads [4]. This only works if a user logs in via the subdomain configured in domain mapping .

Page settings

This is only accessible if a domain is set for this account. Here you can customize some organization-individual links in the system. With the tabs for German and English language, you can switch between both languages:

  • Page title: Define a custom title in niotix [1].
  • Imprint Link: Define where the link to the imprint leads (e.g. an external website) [2].
  • About us Link: Define where the link to the about us leads (e.g. an external website) [3].
  • Copyright Text: Define how the link to the copyright in the bottom line should be named or use this field for a custom name for a link to another page [4].
  • Copyright Link: Define where the link to the copyright or a custom page leads (e.g. an external website) [5].

UI color theme

This is only accessible if a domain is set for this account. With the tabs “light” and “dark” you can switch between different themes and customize the wallpaper, logo etc.

  • Background: Set a custom background for the login-page – only functions when the domain from “domain mapping is used” and all other pages after logging into niotix.

  • Logo: Insert your own logo that will be displayed in the upper left corner, e.g. your company logo. Ideally, the logo should be a PNG file with a transparent background and in widescreen format (4:1 relation).

    It is recommended to have two versions of the logo, one for light and one for dark mode.

  • Highlight color: Select the highlight color – e.g. for selected menu items or headlines. You can choose between six colours or add a custom color via HEX color code. Users can change this setting for their browser via the “gearwheel”-button on the top right corner later.

  • Logo text: Set a custom text displayed beside the logo on the top left corner.

  • System Font: You can now choose “Vollkorn & Poppins” in addition to the previous “Roboto” font, which matches with our new branding.

  • Background on favorites page: For your favorites page you can choose between the default background color or your selected background image as background.

INFO: The system is using the logo, background and colour from the system owner (“root account”) for creating new accounts.

Email settings

You can customize the outgoing system emails which are send to users (e.g. for resetting the password) for each account.

If you want to send out system emails from your domain (e.g. “noreply@mycompany.com”), you need to configure the email server in “Settings > Accounts > Email Server Settings” first. Otherwise, niotix will use its default settings (if set in case of an on premise installation).

niotix provides the possibility to customize different system emails to your needs, e.g. include your organization-specific welcoming or different languages.

To use advanced features of HTML emails, niotix uses the template engine pug. With pug, you have a user friendly and simplified version of HTML to write custom emails. To learn how to use the pug template engine, have a look at https://pugjs.org/ on the right side in the section “language reference". For a quick start, niotix already provides some examples which are ready to use.

You can set up custom emails for:

  • Password changed: The email users will receive when the password was changed.
  • Password forgotten: The email users will receive when they reset their password.
  • Activate account: The email users will receive when a new account is created.
  • Account locked: The email users will receive when the account was locked due to too many wrong login attempts.
  • Connector connection error: The email all users with the permission “SystemNotication.read” for the selected account receive, if a connector in the “settings > accounts” is in a defective state.

For each template, you can define:

  • Subject: the title of the email [1]
  • Content: the body (text) of the email [2]

Beyond this, niotix allows using variables (placeholders) which are used in the emails. All available variables in the subject and content are displayed directly under the corresponding text boxes [3]. You can set variables with the textfields:

  • Site name: Use this placeholder to define the name of your plattform [4].
  • Site base URL: Use this placeholder to define the custom domain in emails [5].

To validate your template, use the “show preview”-button [6]. If successful, niotix will show you a preview in a new window. If the template contains an error, the error will be displayed.

Customer feedback

With the appropriate root administrator permissions, this field will appear on the system page. Here you can set the email address to which the help and feedback requests that users enter via the question mark button at the top go. You can put in the fields the addresses to which error messages (“I don’t like something”) and the other two feedback requests (“I like something” and “I have a suggestion”) will be sent.

Custom Terms & Conditions

If you resell niotix licences to your customers, it may be necessary to define your own terms of use. This is possible under this paragraph.

By activating the switch “Use custom terms & conditions”, your own terms of use are activated. If this switch is deactivated, the Digimondo terms of use are used.

For some changes to the terms of use it is necessary to have them confirmed again by the users, even if consent has already been given. This is possible if the checkbox “Request consent again from users who have already given consent”.

❗️By default, the checkbox is set so that the consent of all users is requested again after each change is saved, even if it has already been granted. To avoid a new request, the tick should be removed before saving the changes.

Announcements

With the announcement tool, you can inform users in your account or sub-accounts directly within niotix. This is helpful in case of new updates, future maintenance slots or company updates. There are two possibilities how to display announcements to users:

  1. As a banner on top of each page (see picture 1)
  2. As a message on the “home”-page (see picture 2)

Picture 1:

Picture 2:

Announcements are displayed to users until the expiration time is over or the user manually deactivates the announcement. Note that, once an announcement is closed, users cannot access it again!

In the overview at “Settings > Announcements”, you can create new announcements [1], see past announcements and their status and edit or delete existing announcements [2].

Create Announcement

To create a new announcement, you first have to select the account for which it will be applied and then click on “create announcement” [1].

In the new window, you can configure your announcement:

  • Type: You can choose between 4 different types of visualizations for announcements (info, warning, error, success), which differ in the background color and icon displayed ([1], [2])
  • Presentation Type: Select whether you want to display a banner or message [3].
  • Include sub-account: If selected, all user in the sub-accounts of the selected account will see the announcement as well [4].
  • Text: Add your announcement-text [5].
  • Display Date: If activated, you can select a timeframe with the date picker in which the announcement will be displayed to the users. It will be automatically deactivated if the end date is over [6].
  • Link: You can add a link to any 3rd-party-site for more information. Just add a URL and name of the link in these fields. The link will be added to the above defined text. [7]

Edit Announcement

To edit an announcement, click on the “pen & pencil” icon in the overview for the corresponding announcement. You can change all settings of existing announcement similar to when creating a new announcement, which is described above.

Permissions

Within this section, you can set up custom user roles for your accounts. Furthermore, you can grant access to different niotix modules for each account.

Modules

niotix provides a module-based approach to extend and tailor its functionality. A module in niotix is similar to an app for a smartphone: It is not part of the core niotix-functionality, can be provided by 3rd parties (beside DIGIMONDO) and needs to be activated separately. In comparison to the core features of niotix, the modules aim to provide business users tailored solutions for certain use cases.

To grant access to existing modules, you first need to select the account for which you want to define the module settings [1]. Depending on the type of installation (on premise or SaaS) and granted permissions by the system administrator, you can see different types of modules.

You activate a module with the toggle button [2]. Furthermore, for each module you can decide if certain, module specific permissions should automatically be assigned to new users, so that they can use the module [3].

Retention Policy

With the appropriate permissions as a system administrator, you can customize the retention periods of Digital Twin data points for sub-accounts. The default retention value for data points before they are removed from the database, which is also used by our SaaS system, is 24 months.

Integrations

Integrations are 3rd-party-systems, which are not part of the niotix core system, but which are integrated via an internal interface.

With the toogle-button for each integration, you can activate an integration for your account or for sub-accounts. IMPORTANT: Once activated, an integration cannot be deactivated anymore.

  • IoT Data Hub Influx Database: This activates the faster Influx database to persist device data. It is prerequisite for using Grafana
  • Dashboard Instance: This starts a Grafana instance to visualize IoT data
  • IEC-60870-5-104 consumer: If installed by Digimondo, you can activate the interface to IEC104-based SCADA-systems. Please contact Digimondo if you are interested in using this integration
  • States Influxdb Datasource: This activates the faster Influx database to use states of digital twins in Grafana.

Role Editor

With the role editor, you can define own roles for your accounts. Use the role editor to represent your organizational roles with individual names and permissions.

This page is separated into 2 tabs:

  • Default role wizard: Select the default roles applied to new users for each scope (digital twin).
  • Role editor: Configure individual roles and edit existing roles for your account (tenant).

Tab ‘Default Role Wizard’

With the default role wizard, you can define which roles are per default assigned to new users for the selected scope. This default setting is applied when you create a new user and do not change the scope-permissions. It helps you to save effort and ensure that new users always get the same permissions for individual digital twins.

First, select the scope for which you want to define the default roles. Then, select the default roles from the dropdown list. To finish, simply click on the “save”-button.

Tab ‘Role Editor’

With the role editor, you can define new and customize existing roles by selecting fine-granular permissions.

To do so, first select the account for which you want to customize the roles. In the next step, you get an overview of existing roles for this account. To delete a role, click on the “trashbin” button for each row. To edit a role, click on the “pen & paper” button. If you want to create a new role, click on the “create” button.

IMPORTANT: A role always belongs to an account. This means, that a role which you define is only visible to (and usable for) the account for which it was defined.

Add new

To add a new role, you need to set up following fields:

  • Role name: the name of the role
  • Role description: a short description of the role’s purpose
  • Icon: Select an icon which represents your role best (optional).
  • Rules: Select the applied rules (permissions; see description below) from the dropdown list by activating the corresponding checkboxes.

Existing rules (permissions)

niotix has a powerful access management with fine-granular rules (permissions) to customize how users can interact with the system. For each role, you can assign different rules.

In general, each rule refers to a data objects in the system and is split into “permission for reading”, “permission for writing/editing” and “permission for creating new data objects”. These permissions are not necessarily equal to visual access to the menu items (e.g. reading a digital twin without access to the user interface is used by some niotix modules). Other than that, permissions to an account are inherited to its children (sub-accounts).

The following list gives you and overview of basic rules in niotix:

  • All.manage:
    • Gives access to all niotix features incl. full rights to edit, delete, create etc. (“everything an account-admin needs to access”): menu “Home”, “Digital twins”, “IoT Data Hub”, “Connected Systems”, “Settings”, “System logs”, “rest API”, “Overview”
    • Should show only content (accounts, twins, etc.) from the corresponding account and its sub-accounts (not parents)
    • In IoT Data Hub, it allows the following:
      • General behavior: the user can see, edit and delete everything from his account and the sub-accounts
      • Applications: See, edit and delete applications of the account and its sub-accounts
      • Consumers: See, edit and delete consumers of the account and its sub-accounts
      • Devices: See, edit and delete devices of the account and its sub-accounts
      • Device Types: See, edit and delete all device types of the account, parental account, and sub-accounts, which have the visibility ‘everyone’, are visible. But only device types of the account are editable (not devices on the same hierarchy level are not visible, eg. customer X, customer Y)
      • Gateway Management: You can create new gateways for your account or its subaccounts, edit existing gateways, and delete gateways.
      • Device Monitoring: All critical devices of the account you are logged in to and its sub-accounts are visible and filterable by accounts. You can edit the devices or create new devices of/ for your account and of/ for its sub-accounts.
      • Gateway monitoring: All critical gateways of the account you are logged in to and its sub-accounts are visible and filterable by account. You can also create an email notification for you and other users in the system for critical gateways that are on alert. Please note that recipients who do not have the all.manage permission will also receive the list of critical gateways accessible to you.
      • Data Sources: See the data sources, but can not edit them
      • Originators: See the originators of the account by which you are logged in and its sub-accounts and edit them.
      • Dashboard Builder: Reporting instance(s) of the account you are logged in to and its sub-accounts are visible in the query. You can see, edit existing, and create new dashboards for this account and for its sub-accounts.
      • Service Builder: All service builder instances of all accounts where the user has IotHub.manage or all.manage permission (not the sub-accounts of these accounts!)
  • All.read:
    • Gives readable access to niotix features relevant for users without any mutation rights: “Digital Twins”, “IoT Data Hub”, “Dashboard Builder”, “LoRaWAN system”, “Settings”, “Overview”
    • No access to: niotix-moduls (e.g. warning app, ticket management), Connected Systems > IoT Service Builder Instances
    • Use for demo accounts that can only be viewed by third parties (e.g. resellers who want to make the system and implemented use cases available to third parties)
  • DigitalTwin: This defines how (if) users can use the digital twin.
    • DigitalTwin.list:
      • menu “Digital Twins” is not shown, but should be needed to access digital twins in the background (e.g. for pinning twins to the “home”-page, using the warning-app)
      • can also be used together with DigitalTwinStates.read to access the “Overview” page
    • DigitalTwin.read:
      • Shows the menu “Digital Twin” with sub-twins
      • Shows the menu “Dashboard Builder”
      • Allows to see the details of a digital twin incl. states, rules, etc.
      • Allows to pin twins to “Home”-page
      • Allows to read all twins and states in “Overview”
      • Where DigitalTwin.list is required, a DigitalTwin.read can also be used
    • DigitalTwin.write:
      • allows to create new twins and edit existing digital twins, but can not delete/disable them
      • can create and edit states and rules, but not delete them
    • DigitalTwin.manage:
      • allows to read, create, edit and delete/ disable digital twins
      • allows to create states and rules for twins
      • allows to see and edit service builder, dashboard builder
  • DigitalTwinStates: This defines how (if) users can use the states and rules of a digital twin.
    • DigitalTwinStates.read:
      • Should not do any changes to the UI - but is needed to give other modules and pages access to digital twins (e.g. the Object-Management-App, Warning-App-Monitor)
      • To be used together with DigitalTwin.list, if no full-read-access to twins should be granted
  • IotHub.manage:
    • has access and edit/create rights to (equals the former n1.0-role “User”):
      • General behaviour: The user can see, edit and delete everything from his account (not from sub-accounts)
      • Applications: all applications of the account (not the sub-account)
      • Consumers: all applications of the account (not the sub-account)
      • Devices: All devices of the account (not the sub-account)
      • Device Types: all device types of the account and device types of parental accounts, which have the visibility ‘everyone’, are visible. But only device types of the account are editable.
      • Gateway management: All gateways of the account (not sub-account) are visible. You can create new gateways for your account, edit or delete existing gateways.
      • Service Builder: All service builder instances of all accounts where the user has IotHub.manage or all.manage permission (not the sub-accounts of these accounts!)
      • Dashboard Builder: Only reporting instance(s) of the account you are logged in to are visible in the query. You can only see, edit existing and create new dashboards for this account (Grafana admin role), not for the sub-accounts.
      • Device Monitoring: All critical devices of the account you are logged in are visible, you can not filter by accounts. You can edit the devices or create new devices for your account.
      • Gateway Monitoring: All gateways rated as critical for the account you are logged into are visible and can be filtered by the warning and alert level. You cannot filter by account. In addition, you can create an email notification for you and other users in the system for critical gateways that are in the alert level. Please note that recipients who do not have this authorisation will also receive the list of critical gateways accessible to you.
      • Originators: See the originators of the account by which you are logged in. You can only edit the originators of this account.
  • IotHub.read:
    • General behaviour: the user can see (not edit) everything from his account (not sub-accounts).
    • Has readable access to (equals the n1.0-role “Read Only”):
      • Applications: all applications of the account (not the sub-account)
      • Consumers: all consumers of the account (not the sub-account)
      • Gateway Management: All gateways of the account (not of the sub-account) are visible.
      • Devices: all devices of the account (not the sub-account)
      • Device Types: all device types of the account are visible
      • Device Monitoring: Only the critical devices and their information of the account you are logged in, are visible. You can not filter by accounts.
      • Gateway Monitoring: All gateways rated as critical for the account you are logged into are visible and can be filtered by the warning and alert level. You cannot filter by account. In addition, you can create an email notification for you and other users in the system for critical gateways that are in the alert level.
      • Originators: Only see the originators of the account in which you are logged in, but you cannot edit them.
    • No access to: Data Sources, Service Builder, Dashboard Builder, Gateway Management & Gateway Monitoring (despite the additional permission Gateways.manage)
  • IsFmAccess.manage:
    • Should include the same features as IsFmAccess.write
    • Should allow to create keys if the permission usermanagement.read and digitaltwin.list or digitaltwin.read/manage is also given
      (Info: A twin can only be selected if with tag “Building”/”Room” or has type building /room and the door-id is set)
  • IsFmAccess.write:
    • allows to access the menu “Key-Ring” and use the key(s)
    • Keychain is only visible, if a key is assigned to the user
  • IsFmTicket.create:
    • Should display a “+”-icon on the top right corner to add new tickets
    • Should show the tile “create new ticket” on the “home”-page if no digital twin is marked as favourite
    • Should show the menu-item “object mgmt > create ticket” if IsFmTicket.read is also granted (tbd)
    • Should allow to create a new ticket (if the permission digitaltwin.list is granted as well to be able to select a twin)
    • Should not allow to see the list of existing tickets
  • IsFmTicket.manage:
    • includes the same features as IsFmTicket.create and IsFmTicket.read
    • enthält die gleichen Funktionen wie IsFmTicket.create und IsFmTicket.read
    • allows to edit and delete existing tickets
  • IsFmTicket.read:
    • allows to access the menu “object mgmt > tickets”
    • displays the “notification” (bell-icon) on the top right
  • IsWarnapp.manage:
    • includes all permissions of IsWarnapp.read
    • displays the menu “administration”, if the module is activated
    • lists digital twins in the “administration”, if digitaltwin.manage is assigned as well
  • IsWarnapp.read:
    • displays the menu “warning monitor”, if the module is activated
    • allows to select a pre-configured digitaltwin in the “warning monitor”, if digitaltwin.list is assigned as well
  • SystemNotifications.read:
    • Sends out notification emails and display a warning-box on the “home”-page if a connector is not working
  • UserManagement: This defines how (if) users can use the user management.
    • UserManagement.create:
      • allows adding new users to the account
      • does not allow to create users for sub-accounts or parent accounts
      • does not show the list of existing users - except UserManagement.read is also assigned
    • UserManagement.impersonate:
      • displays a small impersonation-icon in the user-table and allows to impersonate other users (the user-table is only visible if UserManagement.read is granted as well)
      • grants the same permissions as the impersonated user - even if this one has more permissions. Consider carefully when you grant this permission.
    • UserManagement.read:
      • allows to access the menu “settings > accounts”
      • allows to see the list of existing users for the account
      • does not allow to see users of sub-accounts or parent accounts
    • UserManagement.manage:
      • includes all permissions from UserManagement.create, UserManagement.read, UserManagement.write
      • does not include UserManagement.impersonate (special exception, as impersonate is a special privilege which not every UserManager should receive)

For a description of all module-specific rules, have a look at the section “modules” in this manual.