Monitoring

User roles

The portal offers 4 user roles:

• Team admin – Main team administrator. Adds and removes users and sets their permissions; creates locations, sublocations, groups and all other portal elements. Naturally has the permission to manage all devices, sensors, alarms etc. A Team admin is an “absolute ruler” over the team and its data. Each Team must have at least one Team admin.
• Device admin – Usually the installation technician or the administrator of the equipment to be monitored. May view data, add and edit devices and sensors, set safe ranges, configure alarm messages, and add devices to locations or groups.
• Report admin – Usually an engineer, technology expert, or a financial administrator. May view measured data and create dashboards, graphs and reports. That is, works with data and overviews to present the measures values in line with the company needs.
• Visitor – May view the measured data but cannot change or add anything. This role is often given by small and medium system integrators to their clients who have no IT or other experts of their own, in order to allow them to view their environment but without the right to change any critical values that could cause harm. It is also suitable for receptionists or security guards who can then quickly check the affected location in case of an alarm.

Different roles (in particular Device admin and Report admin) can be combined as needed. On the contrary, in small-scale installations it may be sufficient to just have one or two Team admins and not worry about differentiating the roles.

	Team Admin	Device admin	Report Admin	Visitor
Add devices
Add teams
Delete teams
Edit devices and sensors
Display sensor readings
Create and edit reports
Download graphs (if available)
Create graphs
Create Dashboards
Create and edit groups
Create reports
Add users
Delete users
Create and edit locations
Batch operations
Create and delete Permission groups

Permission groups

Within a team, everyone can see and work with everything, if they have a role with sufficient permissions. On the contrary, permission groups can be used to grant access to specific elements only (devices, sensors, groups etc.) to individual users.

This allows to have a single team supervising multiple sites (e.g. server houses in Prague, Berlin and London) but at the same time restrict the values visible to individual employees to “their” site only. Team admins can still access everything.

In a similar way, permissions can be fine-tuned down to the level of sensors. For example, IT personnel can be only allowed to monitor the environment in their racks, even if thermometers that the kitchen staff is responsible for are connected to the same Poseidon device.  That way, the IT personnel cannot interfere with the settings of reports that the kitchen staff need for GAMP5 and HACCP.

Permission groups are a powerful tool, so their implementation needs to be carefully planned and executed. For that reason, only Team admins are allowed to create and manage Permission groups. Other users have lesser roles (or their combinations). It is possible to use Permission groups to limit the access by other Team admins; however, these Team admins can always use the permissions associated with their role to grant themselves access to everything.

With Permission groups, access can be granted independently in a fine-grained way to various elements:

• Devices
• Sensors
• Dashboards
• Graphs
• Reports
• Device groups
• Locations

The settings for individual elements are independent. This means that a user who is granted access to a location does NOT automatically receive access to devices and sensors in that location. Likewise, if a user is allowed to view a sensor, the user is NOT automatically granted access to the corresponding device.

Access to a device allows the user to view the device status, NOT the readings of its sensors. Likewise, permissions to work with a device group or a location only give access to data on that level. For example, for a location you can see that 6 sensors are OK and one is in alarm; however, if you don’t have the permission to work with that sensor, you will not know which one it is.

Elements that are not associated with any Permission groups are visible to all team members. This is to make sure that existing users, or users who do not need such a powerful tool, do not have to immediately deal with Permission groups. Therefore, nothing changes for existing customers. Similarly, customers who want to use Permission groups can start by creating a “default” group for all existing and new elements.

Gradually, Permission groups will be applied to XML exports, SNMP, and so on.