It is possible to use a server for several small projects, e.g., for some separate areas with few devices. To configure this mechanism you must: 

1. Create or generate the required number of root groups as explained earlier. Each root group stands for a single project.

2. Add the required number of subgroups (depending on the project structure) as described earlier. 

3. Rename the default administrator role into the master administrator as this user has permissions to monitor and configure all projects available on the server.  

4. Create a profile for the 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. 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;

5. Edit the default profiles or create new ones for the user and 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. 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;

   User must have such permissions as: 

   • calls: can call to intercom;

   • conversations: can create conversation message;

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

6. Add users to the server.

7. Apply corresponding profiles to 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.