Types of access validations

When an access request is made to a device, several validations are performed to check whether access will be allowed or denied.

Validations occur in the order shown in the following diagram, starting with the itemSend access request, which represents the access attempt being made on a device and sent to the system.

If one of the verifications is not considered valid, the access is denied. Otherwise, the next validation is carried out and, if all are considered valid, access will be allowed. At the end of the process, the result is sent back to the device, which allows or denies access, depending on the response received.

Check all validations performed by the system:

All validations are listed below, along with which verifications are made on each one. This way it is possible to examine the procedures checked at each step of a validation, and try to identify the reason why an access attempt is blocked. The list also indicates whether the validation is always made by the system by default, or if it might not be checked (being disabled, for example):

• Validate credential: verifies whether the person has an access credential registered and if it is neither blocked nor expired.
• Validate role suspension: verifies, among all of the person's roles, whether they have a suspension on the access date. There must be at least one role active (without suspension) for the access to be valid.
• Validate level: checks, among all the person's roles, if any of them do not validate the level (in this case, access is valid). Then, if the device either controls only entry or only exit, the current level of the person must be equal to the level of the device order. If the device controls both directions, the current level of the person must be equal to the origin or destiny level of the device.
• Validate anti-double control: checks, among all the person's roles, if any of them do not validate anti-double (in this case, access is valid). Next, it is checked whether the destination location of this request is the same as the last location accessed by the person, that is, the location where the person is already. If it is the same location and the anti-dual validation time has not yet passed, access is denied.
• Validate location time slot: checks, in the papers to be considered for the person, if any of them do not validate the location's time slot (in this case, access is valid). It then checks whether any of them do not have a list of time slots associated with the location or time slot for the day of the week of this request (in these cases, access is invalid). Then, it is checked whether the time of the access request is within the time range of the respective day (or, if the current day is a holiday, within the holiday time range).
• Validate the person's time slot: checks, in the roles to be considered for the person, if any of them do not validate the person's time slot (in this case, access is valid). It then checks whether any of them do not have a schedule, the correct day for validation, or time slots defined for that day (in these cases, access is invalid). Then, it is checked whether the time of the access request is within the time range, on the correct day of the schedule.

In-between workdays control and role suspension control

In the Roles screen, if the Controls in-between workdays button is active, the location controls the access of workers by validating the in-between workdays configurations of the roles. If deactivated, the worker will have the access granted, regardless of having a role with the in-between workdays control active.

In the same screen, if the Control role suspension (absences) button is enabled, the location will check whether a role is suspended. If this is the case, the entry will be blocked.

See also:

• Access control