Profiles

Not every user requires access to all menus and settings of the Link server. In the section, you can create general profiles (roles) for different user types and provide more or fewer permissions for them. These profiles will be applied to all users.

Below there are examples of the most common profiles that can be useful for your projects:    

• administrator: users that control the whole system and have all possible permissions to perform system installation, configuration, and support;

• concierge: users that interact with residents and visitors, manage residents group(s), devices, and access conditions, send announcements and messages;

• user: an ordinary profile that has access to a personal account where it's possible to change personal settings, interact with messages, check the status of personal/shared devices, and their logs, change device settings, generate guest passes and check available identifiers and access restrictions. 

Open

Here is the list of all possible permissions that can be provided for profiles: 

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

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

• backups: can create/delete/view/apply backup, apply/download backup file;

• call history: can view all call history;

• calls: can receive call like concierge (from apartments residents), can call to all users, can call to intercom (panels), can intercept call like concierge;

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

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

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

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

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

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

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

• licenses: can edit server licenses, can edit user licenses, can edit the number of licenses for a root group;

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

• profiles: can view roles, can create/edit/delete role, can grant permissions more than his own, can view all roles, not available roles only;

• project settings: can change/view project settings, can import device backup data, can view management company info;

• schedule: can view/create/edit/delete schedule, can view all schedules;

• system: can view audit/system info;

• users: can edit/view all users, create/edit/delete user;

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

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. 

Open

As a result, the profile will be added to a list where you can edit or delete it. Also, you can filter profiles by name.  

To apply the profile to a user you can in the Users tab.

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.  

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.    

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;

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. 

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 

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.