Some of the technical content on this site is only available in English.

Unit user management Beta

Overview

This section describes how units are managed from the perspective of users who have the role of unit manager. It assumes that the unit has already been moved in by a user with the system manager or owner access. Unit managers do not move in their own units.

The role of unit manager allows certain users to have a more granular control over the access of users to the units that they belong to, without having to depend on a system manager to do this for them.

Unit manager viewUnit managers have a more restricted view of the access control elements in Nebula

For a fuller description of how to manage units from the perspective of a system manager, or owner, see the section on creating units.

Considerations

Unit managers cannot see any access control elements at the installation level. Instead, they manage their own unit, mainly by allowing other users access. Although unit managers have the ability to create other unit managers, it's expected that their main task is to give access to other users by assigning them keys.

Manager views

The unit manager view of Nebula differs from the system manager view in that unit managers see a reduced amount of sections. These sections are the following:

  • Users
  • Activity

Users

Unit managers create users in their unit in a similar way to how a system manager creates users at the installation level. They do not create users using the move in feature. However, the major difference is that when they create unit users, at the same time they can indicate the access that the user will have.

Unit manager creating a unit userWhen creating a unit user, a unit manager can at the same time create access for that user

They do not have to create access rights for the unit as these have already been created by the system manager.

Access

Unit managers grant access to users by assigning them previously created access rights within the Access section of the Create user screen. They also have the option to add a different schedule to the one already created at the installation level. To do this, they would select the Limited option in the Create user screen.

At the unit level, schedules can only be the same or more restrictive than those already assigned to the unit.

For example: if the tenant of an apartment (a unit manager) has only been given access to the pool from 08:00 to 20:00, the tenant cannot invite other users to the pool 24 hours a day.

If a unit manager tries to apply a schedule that's not available to another user, the warning message "Time outside limits of schedule" displays. This indicates that the access must be restricted to the schedule that is applicable to the unit's previously defined access rights.

Note that if an access right schedule at the unit level is marked as Always, the Always option will also display on the Access schedule for the unit user being created. However, if the access right schedule at the unit level includes some schedule restrictions, the option Same as defined in unit will display.

Unit manager creating access for a userA unit manager can only assign previously created access, or a more restrictive one

Selecting the option Same as defined in unit means that the user you're creating will have the same schedule as the one previously defined in the unit. The schedule of this access is displayed by placing the mouse over the information icon (:information:). For example: "Monday to Friday, 08:30 - 17:30".

Same as defined in unit optionThe information icon displays the schedule of the previously created unit access

Assigning keys

Once unit users have been created and their access defined, you can then assign them keys. Unit managers assign keys in the same way as system managers assign keys to users.

Unit manager assign keysUnit managers assign keys to unit users in the same way as system managers at the installation level

Note that unit managers may or may not assign physical keys (fobs, cards or wristbands) to users, depending on the specific use case.

On the one hand, the assignment of physical keys might be done by users with management roles at the installation level. For example, a concierge on the front desk of a hotel or apartment block.

On the other hand, there may be cases where a unit manager will assign physical keys themselves. For example, a tenant in multi family housing could be handed a batch of physical keys at the beginning of their stay in a property because they need to provide keys to cleaners, dog walkers, etc.

Associated user

In the user profile under Associated user, you can see the user who either created that specific unit user, or shared a key like an Apple Wallet key with them.

This is useful because, in some cases, you may find that units contain two or more users with the same name. The Associated user can help you avoid doubt in such a situation.

Also note that if the associated user's schedule is changed because, for example, the system manager has modified an access right in the unit that affects this user's schedule, the unit manager may have to check the access of the other users who have had keys shared with them.

This only applies if a limited user schedule has been reduced from the previous schedule that belonged to the user. In this case the following warning message will display:

The previous schedule has been modified. Check the schedule and update it if required.

The user manager should then check the user's access matches the required state and if not update it accordingly.

Activity

See the section on unit activity.

Salto Systems, S. L. uses third-party data storage and retrieval devices in order to allow secure browsing and gain a better understanding of how users interact with the website in order to improve our services. You can accept all cookies by clicking the "Accept cookies" button or reject their use by clicking the "Reject cookies" button. For more information, visit our Cookies Policy