Tabs
Start
After succesful login, the administrator is presented with a start page showing:
- Latest alerts
- Latest events
- Offline doors
- Statistics on number of doors, users, devices, etc.
Roles
Roles is one of two ways to give access rights to a user (the other being Assignments). A role connects one or more users to one or more policies. Roles have names and would typically express the user's job function, e.g. "technician" or "student". A user can have many roles.
More information about roles can be found here.
Assignments
Assignments are identical to roles, but have a different purpose: temporary access rights. Organizations that often need to create temporary access rights for users can use assignments for this, thereby keeping the list of roles short and tidy.
More information about assignments can be found here.
Visits
The purpose of Visits is to enable people who are not registered users in the system to access one or more doors during a limited time. A typical use case could be an event where you want the guests to be able to let themselves in through the front door, but only on the night of the event.
When creating a new visit, the system will generate a URL (web address) that can be pasted into an email and sent to the visitors. When the visitor clicks the URL in the email application on their smartphone it takes them to a web page where they will see an "Open" button for each door included in the visit.
It should be noted that Visits is relatively low security because anybody who has access to the URL can open the door, and it is not possible to know the identity of the actual person who did the opening. On the other hand the access buttons are only visible and possible to use during the time of the visit.
More information about visits can be found here.
Users
Users are the end users of the system that need to be able to open doors. Access rights are always set for a user (using either Roles or Assignments).
A user can be the owner of one or more devices. Every device that a user owns, will inherit the access rights of its owner.
In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Department and Employee ID.
A personal PIN can also be set for a user. Some policies require the entry of a correct PIN to open the lock (typically for high security doors or out of office hours). The PIN needs to be numeric and four digits long.
A user can also be shared with other organizations, which is explained in the section on delegation.
More information about users can be found here.
Devices
A device must have a name and a type. Currently, two types of devices are supported: Card with ID and Mobile phone. The latter refers to the Telcred Entry app, which is available for both iOS and Android.
A user can have one or more devices, e.g. a card and a phone or two cards. All devices belonging to the same user will inherit the access rights for that user. A device can only belong to one user at a time, but it is possible to reassign a device to a different user.
More information about devices can be found here.
Events
Events include the results of user interactions, i.e. access granted or denied, as well as different types of alerts, e.g. door forced open or door left open. In the GUI, events can be filtered and sorted.
Events based on PIN only credentials cannot always be attributed to an individual user. This is because there is no guarantee that the PIN is unique (several users could have the same PIN). If the user's PIN is indeed unique, the system will display the user's name in the event log. If not, no user will be displayed in the event log.
More information about events can be found here.
Notifications
An administrator can setup a Notification in order to get an email, an SMS, or both, when certain events occur. It is possible to specify which types of events that should trigger a notification, and also when notifications should be generated (e.g. only outside office hours).
More information about notifications can be found here.
Policies
Policies express access rights, i.e. the right to open one or more doors. A policy is defined by a combination of:
- one or more doors
- a schedule
- a credential
The supported credential types are:
- card only
- card + PIN
- PIN only
- remote (the Telcred app)
More information about policies can be found here.
Schedules
Schedules are used to:
- Control when a door should be single locked, double locked or unlocked
- Specify when a policy is valid
A schedule contains one or more schedule items. A schedule item can occur once, or recur weekly or yearly.
It is possible to define that a schedule item should be excluded from the normal schedule, which can be useful to manage e.g. public holidays.
More information about schedules can be found here.
Doors
The Doors tab is used to change the door settings, e.g. access time, "open too long" alarm, and unlock schedule. It is also possible to check the status of the door (if it is locked and closed) and to perform the following actions:
- Grant access
- Manually unlock
- Manually lock
- Return to schedule
More information about doors can be found here.
Door groups
Door groups are collections of doors. The main purpose of door groups is to make it easy to create policies / access rights for groups of doors, without having to list all the individual doors.
Door groups is a generic construct which can be used to express any logical grouping of doors, e.g. site, floor, type of room, security level, geographical area or something else.
More information about door groups can be found here.
Controllers
A controller controls one or more doors and has a number of settings related to the door hardware, e.g. the lock configuration, type of reader, if a door monitor or REX-button (REquest to Exit) is used etc. The controller also has settings related to its own time zone, connection mode and firmware.
Typically, the controller settings will be done by the installer / integrator and not by the end customer administrator.
More information about controllers can be found here.
Hubs
Hubs are only used in connection with wireless locks from SimonsVoss SmartIntego or Assa Aperio. Before a hub can be linked to a controller, it needs to be created here.
More information about hubs can be found here.