How to configure access rights for separate projects?

Use a single server to manage several small projects — for example, separate areas with a limited number of devices. In this case, each root group stands for a single project. Administrators will only see the information related to their group, including subgroups, devices, users, roles, access rules, and logs.

To manage and monitor a specific project, an administrator must be added to its root group. They won’t have access to any other projects unless explicitly assigned. 

If you are going to use this mechanism, it is required to limit the administrator default profile as it has permissions for access to all data available on the server. This default role can be renamed as the master administrator and used for those who monitor and configure all projects available on the server. So, for the root group administrator, a new profile must be created. You can use one profile for all projects or create it for each project. Also, user and concierge profiles can be created for all or each project.    

Creating a root group administrator profile

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

2. Click the ➕ icon in the lower-left corner.

3. Enter a name for the profile, such as “Root group administrator”, and add a description if needed.

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;

5. Add other available profile types that this type can edit (if necessary), e.g. user, concierge.

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

Setting permissions for users and concierges

It is very important to set permissions for user and concierge profiles correctly because this will determine their functionality and scope. You can edit the default profiles or create new ones and the set of permissions can differ depending on the project. But the obligatory permissions for concierge are the following:  

• 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;

User must have such permissions as: 

• calls: can call to intercom;

• conversations: can create conversation message;

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

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 

Let’s imagin you 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;

     Open

     

     
     
     

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;

     Open

     

     
     
     

4. Create a profile for root group administrator as they must see only to their root group, its subgroups, devices, users, roles, access rules, 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.  

     Open

     

     
     
     

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.

   Open

   

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.

   Open

   

    

   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.