Skip to content

Physical Access Control administration

Physical Access Control administration defines who can use a controlled opening, when access is permitted, and how that configuration reaches the site's controllers. Open General Administration, select the site, and locate Physical Access Control Settings.

Danger

A saved portal record and a controller-applied configuration are different states. Review the configuration queue and test at the controlled opening before treating a change as complete.

Permissions

The section is available only when the selected site has the Physical Access Control module and your assignment permits access.

  • Access Control Viewer users can inspect the area but cannot add, save, delete, import, or synchronize configuration.
  • Access Control Admin users and administrators can modify the ordinary access-control records within their assigned scope.
  • Card Formats is shown only at Global Client Admin authority or higher.
  • Import Credentials is hidden from viewer-only users.

The legacy Reader and Reader Group actions appear only when the site has at least one active controller other than Azure or AllBox. Azure hardware is normally managed from the controller's Hardware Setup action.

Configure in dependency order

Use this order for a new site or controller:

  1. Create the system or controller and its interfaces or hardware.
  2. Define schedules.
  3. Configure readers and reader groups when the integration uses them.
  4. Build access groups from the appropriate readers, reader groups, access points, strikes, and schedules.
  5. Configure card formats before issuing non-mobile credentials.
  6. Create or import credentials and assign at least one access group.
  7. Synchronize the appropriate records and review the configuration queue.
  8. Test a representative credential at each affected opening.

Changing an upstream item can affect everything below it. For example, deleting a schedule can clear reader, hardware, queue, and access-group references.

Understand the two layers

Layer What it proves
Portal configuration The record and its relationships were accepted by TEKControl.
Controller delivery A command was queued, attempted, and returned a result for a particular controller.
Field verification The physical opening behaves as intended with the intended credential and schedule.

Do not infer controller success from a portal success notification. Synchronization can be immediate for some integrations and queued for others. A controller can also accept data that is logically wrong for its wiring or card format.

Safe change practice

  • Record the current controller, external IDs, schedules, access groups, and credential scope before a material change.
  • Change one dependency layer at a time.
  • Use a non-critical reader and test credential first.
  • Review pending and failed commands after each synchronization.
  • Avoid deleting records merely to correct a mapping; deletion can remove dependent associations.
  • Use audit and credential history when reconstructing who changed a record.

See Troubleshooting when saved configuration does not produce the expected physical result.