FAQ - Frequently Asked Questions

Answers to common questions about how ACCELERO works.

How does automatic operator logoff work?

Automatic operator logoff is a security feature that addresses two distinct situations:

Situation 1: Prolonged Inactivity

When an operator spends a long time without performing any action in the system.

Required configuration:

1. Per operator: Enable the "automatic logoff" flag on the operator registration screen
2. Global: Configure the allowed inactivity time through the menu Advanced > System > System - Advanced

How it works:

• The system detects operator inactivity
• If it exceeds the configured time AND the operator has the flag enabled
• The operator is logged off automatically
• A new login is required

Individual Configuration

Each operator can have automatic logoff enabled or disabled individually.

Situation 2: Browser Closing

When an operator closes the browser window.

How it works:

• The browser sends a signal (keepalive) to the ACCELERO servers every 30 seconds
• If the server does not receive any signal from the browser for 90 seconds
• The session is automatically ended

Automatic and Non-Disableable

This feature is automatic and cannot be disabled. It is a fundamental security measure.

See Operators for detailed configuration.

How do I configure anti-passback?

For the anti-passback (APB) feature to work properly, two configurations must be made simultaneously:

1. Configuration on the Area

Path: Settings > Areas

Enable anti-passback control for that specific area.

Flag: "Control anti-passback"

2. Configuration on the Category

Path: Settings > Categories

The person must have at least one category with the "Control APB" flag enabled.

Flag: "Control anti-passback"

Operational Flexibility

This way, you can configure areas that have APB control while leaving some people not subject to this control (usually the operations team).

Configuration example:

Area: SERVER ROOM
- Control anti-passback: ✓ Yes

Category: EMPLOYEES
- Control anti-passback: ✓ Yes

Category: SECURITY
- Control anti-passback: ✗ No

Result:
- Employees: subject to APB in the Server Room
- Security: NOT subject to APB in the Server Room

See Areas and Categories for more details.

How do I configure a duress identifier?

ACCELERO allows people to have panic/duress identifiers.

Two Configuration Methods

Method 1: Exclusive Identifier

• Create identifiers specifically for this purpose
• A dedicated "panic identifier"

Method 2: Identifier with Special Marking

• A permanent identifier with a special panic/duress marking
• The person uses the same identifier, but with a special code

System Behavior

When the user presents a panic/duress identifier at any reader in the system, the system takes different actions depending on whether the controller is online or offline.

If the Controller Is ONLINE

Actions performed:

1. Additional log: The server generates an additional event log reporting that there was an access request under duress

2. Broker message: The server publishes a specific message on the system's message broker, which can be captured by other systems (alarm centers, for example) enabling integrations

3. Configurable action: You can configure the system's action:

Configuration	Behavior
(1) Automatic passage	Automatic passage must occur in these situations
(2) Apply normal rules	Access rules must be applied normally, therefore allowing the possibility of access denial

Configuration path: Advanced > System > System - Advanced > Action in a duress situation

If the Controller Is OFFLINE

Actions performed:

1. Normal control: The controller performs "normal" access control, running the usual access permission checks

2. Offline logs: When downloading the logs to the server once the connection is reestablished, the server generates additional event logs identifying the passages made/denied under duress

Door with Delay

In the "Door with delay" operating mode, the duress system works slightly differently.

When an access request is identified as duress, the controller always triggers:

• Relay ALRM2 together with relay LOCK1 (if access was authorized)
• OR relay ALRM2 together with relay ALRM1 (if access was not authorized)

See Identifiers for detailed configuration.

The person is being granted/denied access... why?

ACCELERO has an "access rules engine" that runs several checks before releasing an access attempt.

Verification Order

The checks are performed in a specific order. If any check fails, access is denied, and a specific event log is generated with the description of the denial reason.

Applied Rules (in order)

Check	Description
Passage timeout	Is the person trying to pass through two blocks at the same time?
Does the identifier exist?	Is that identifier number registered within ACCELERO?
Is the identifier type accepted on that channel?	Every identifier has a type. In the controller's channel configuration, is that type marked to be accepted?
Is there a person associated with the identifier?	Identifiers that are not associated with anyone are not accepted
Is the person enabled?	Every person has an individual "Enabled" flag. Is the person trying to pass enabled?
Is the identifier enabled?	Every identifier has an individual "Enabled" flag. Is the identifier enabled?
Is the identifier valid?	Every identifier has a start/end validity date. Is the access attempt happening within that period?
Does the person have an enabled company?	Within the person's list of companies, is there at least one company with the "Enabled" status? IMPORTANT: If the person has no associated company, ACCELERO does not run this check
Is the area enabled?	Is the area where the access is happening set with the "Enabled" flag active?
Is the time range accepted?	Among all of the person's categories, is there at least one that allows access in that time range, in that specific area?
Anti-passback check	If the person is already in the area they are trying to access, is there a need to block due to APB (checking the area configuration and the person's categories)?
Is the area at capacity?	Every area can have a capacity control. If the control is enabled, has maximum capacity already been reached?

Quick Diagnosis

Knowing the checks that are performed, and the order in which they are done, lets you accurately check whether all configurations were made properly, and quickly trace any inconsistency.

How to Diagnose Problems

1. Check the Event Log

The event log shows exactly which check failed.

Path: Logs > Event log

2. Verify each item sequentially

Follow the order of the table above and check:

• ✓ Does the identifier exist in the system?
• ✓ Is the identifier type enabled on the channel?
• ✓ Is the person associated with the identifier?
• ✓ Is the person enabled?
• ✓ Is the identifier enabled and valid?
• ✓ Does the person have a valid category?
• ✓ Does the category allow access in that area AND at that time?

3. Use the Effective Permissions Report

For detailed troubleshooting, use the specific report.

Path: Reports > Effective Access Permissions

See Reports - Effective Permissions.

Diagnostic Tool

The Effective Permissions Report shows exactly which areas/times the person has permission for, making troubleshooting enormously easier.

Other Questions

Didn't find your question?

If your question is not listed here, check:

1. Specific documentation: Browse the relevant documentation sections

   • Access Policy - Understand the fundamentals
   • People - Registration configuration
   • Categories - Access rules
   • Areas - Area configuration

2. Technical Support: Contact IONGRADE technical support

   • Support e-mail
   • Support phone
   • Customer portal (if available)

3. Operation Log: The answer is often in the logs

   • Logs > Operation log - For audit questions
   • Logs > Event log - For access questions
   • Logs > System log - For technical questions

Next Steps

• Access Policy - Understand the fundamental concepts
• First Login - Start configuring the system
• Operation - Learn about daily operation
• Maintenance - Maintenance procedures