Page Comparison

...

• Server administrator: Full access to manage all aspects of the server. This role includes creating and editing user groups and roles, managing all objects, including rooms, virtual numbers, and devices. The Server Administrator has access to all data on the server, including logs and archives, and is responsible for backups, data recovery, security settings, and system audit.

• Company administrator: Management rights within the company. The Company Administrator can create subgroups, assign responsible administrators, and distribute licenses among users. Their role is to configure and manage the company’s resources and set access restrictions for subordinate roles, such as the Site Administrator.

• Site administrator: Limited management rights within the company’s resources. The Site Administrator can manage assigned resources, such as rooms and devices, view and edit data within their group and subordinate groups, and control room bookings and access to facilities. Site Administrator permissions are determined by senior administrators and restricted by hierarchy.

• User: Standard user access to a personal account. The User can configure their profile, view their devices and bookings, create guest passes, and receive messages. Access is limited to personal settings and interaction with shared functions without control over system parameters.

• Concierge: A role for interacting with residents and guests. The Concierge manages resident groups, sends announcements and messages, controls room bookings and access to facilities, and has access to group information and devices to ensure security and communication.

...

How to obtain each role

1. Company Administrator: Access to this role can only be obtained after completing validation with our technical support. Once validated, the necessary permissions are granted.

2. Site Administrator: There are two ways to obtain this role:

   • Invitation: The Company Administrator invites the user to a specific group in the Object Group section.

   • Self-selection: During registration, the user can choose this role, labeled as Dealer/Installer.

3. Concierge: The Concierge role is assigned manually by the group administrator. To do this, the administrator uses the New User dropdown and selects the Concierge role from previously added roles in the Profiles section.

4. User: A user can either register independently on the website or be added manually:

   • Self-registration: The user completes registration on the website.

   • Manual addition: The administrator uses the New User dropdown and selects the User role from the Profiles section. If the user is added manually, a QR code and a standard code are sent to the specified email for verification and to complete registration.

Permissions Table for Each Role

How to create a profile 

1. Go to the Profiles tab of the User management section.

2. Click the plus icon (in the low left corner).

3. Enter a profile name and add a description (if required).

4. Select the permissions (and, corresponding, the functionality)you want this user type to have. 

5. Add other available profile types that this type can edit (if necessary). For example, for the administrator type, all profiles can be added in this section.

6. Save data by clicking the corresponding button in the left low corner. 

...

To apply the profile to a user you can in theUserstab.

Independent projects on the one server

It is possible to use a server for several small projects, e.g., for some separate areas with few devices. In this case, each root group stands for a single project. The administrators see only their root group info about subgroups, device(s), user(s), role(s), access rule(s), logs, etc. In other words, the administrator must be added to the root group to manage and monitor all linked with this group. So, they can not influence and access other projects they are not linked with.  

...

How to create a root group administrator profile

1. Go to the Profiles tab of the User management section.

2. Click plus icon (in the low left corner).

3. Enter a profile name (e.g. root group administrator) and add a description (if required).

4. Select the following permissions: 

   • access restrictions: can view/create/edit/delete access rules;

   • announces: can create/edit/delete/send announces, can view announces;

   • conversations: can create conversation/conversation message, can delete conversation, can accept messages from descendant users;

   • devices: can view device tasks, can create/edit/delete/view devices, can view device events;

   • elevators: can create/edit/delete elevator, can view elevators;

   • emergency alerts: can view emergency alerts, can create/edit/delete/playback emergency alerts;

   • forward rules: can view/create/edit/delete forward rules;       

   • groups: can delete/edit group, can create group-descendant;

   • identifiers: can view identifiers; can create/edit/delete identifier; can create guest identifier, can import/export identifiers, can view ACS logs;

   • markers: can view/create/edit/delete/apply marker;

   • profiles: can view roles, can edit role (these rules are applied to the list of available profile types set in the corresponding section);

   • schedule: can view/create/edit/delete schedule;

   • users: create/edit/delete user;

   • virtual numbers: can create/edit/delete/activate virtual number, can mark system virtual numbers;

...

After the profiles are created, they must be applied to the pre-created users. Then users must be added to the groups: root group administrator must be added to the root group (the main progect group), all other users must be added to the corresponding groups.   

Example of server configuration for hosting several projects 

For example, we are managing 2 separate houses and must create conditions for users to interact only with houses groups they live in. Each house group must have its own administrator with the permissions to edit the list of users, devices, groups, apartments, etc. only within the house they are added to. In addition, each group must have its own resident users and concierges, who must be able to normally interact with each other, but not overlap with neighboring house group.

1. As the local (root group) administrators of each house have advanced rights only in their groups, the server must have a master administrator who can configure the whole server. So, you must create the profile for this master administrator. The default Administrator profile has all necessary permissions, so leave it, but rename to the master administrator. Apply this profile to the user who will manage the whole server.

2. Edit the default profile or create a new one for users and set the permissions (they can differ depending on the project). It is very important to set permissions because this will determine their functionality and scope. You can use one profile for all projects or create profiles for each project. In this example, we create separate profiles for each project. User must have such permissions as: 

   • calls: can call to intercom;

   • conversations: can create conversation message;

   • identifiers: can view identifiers; can create guest identifier;
     

     

3. Edit the default profile or create a new one for concierge and set the permissions (they can differ depending on the project). It is very important to set permissions because this will determine their functionality and scope. You can use one profile for all projects or create profiles for each project. In this example, we create separate profiles for each project. The obligatory permissions for concierge are:  

   • announces: can create/edit/delete/send announces, can view announces;

   • calls: can receive call like concierge, can call to intercom;

   • conversations: can view all conversations, can send messages to all, can create conversation/conversation message, can accept messages from descendant users;

   • emergency alerts: can view particular emergency alerts, can playback emergency alerts;

   • markers: can view marker;
     

     

4. Create a profile for root group administrator as they must see only their root group, subgroups, device(s), user(s), role(s), access rule(s), logs, etc. You can use one profile for all projects or create profiles for each project. In this example, we create separate profiles. This profile must have the following permissions:

   • access restrictions: can view/create/edit/delete access rules;

   • announces: can create/edit/delete/send announces, can view announces;

   • conversations: can create conversation/conversation message, can delete conversation, can accept messages from descendant users;

   • devices: can view device tasks, can create/edit/delete/view devices, can view device events;

   • elevators: can create/edit/delete elevator, can view elevators;

   • emergency alerts: can view emergency alerts, can create/edit/delete/playback emergency alerts;

   • forward rules: can view/create/edit/delete forward rules;       

   • groups: can delete/edit group, can create group-descendant;

   • identifiers: can view identifiers; can create/edit/delete identifier; can create guest identifier, can import/export identifiers, can view ACS logs;

   • markers: can view/create/edit/delete/apply marker;

   • profiles: can view roles, can edit role (these rules are applied to the list of available profile types set in the corresponding section);

   • schedule: can view/create/edit/delete schedule;

   • users: create/edit/delete user;

   • virtual numbers: can create/edit/delete/activate virtual number, can mark system virtual numbers;
     
     Also, the root group administrator must be allowed to edit all subordinate profiles, so select the corresponding profiles of user and concierge as Available profiles.  
     

     

5. Create a root groups that stand for the houses projects, e.g., the 1st group is A residence, and the 2nd is B residence.

6. Add the required number of subgroups (depending on the project structure). 

7. Add users to the server and apply created profiles to the corresponding users.

   

8. Add users to the created groups: root group administrator must be added to the root group (the main project group), and all other users must be added to the corresponding groups.

   

   As a result, the administrator added to the root group can manage and monitor all linked with this group users, access restrictions, devices, schedules, etc. So, they can not influence and access other projects (root groups) they are not linked with. But both root groups are available for the master administrator.