Telcred documentation - User contributions [en]

Commands

2026-02-17T15:31:05Z

Telcredstaff: /* Perform: On doors */

== Overview ==

A ''command'' is one or more predefined actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]] being activated.

Some use cases for commands include:
* Perform an action simultaneously on a set of doors, e.g. block all doors in a section of the building to achieve a "lockdown".
* Interact with an external system (e.g. arm or disarm an intrusion detection system or turn on the lights).
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule).

=== Origin dependency for commands and relevance for triggers ===

With ''origin'' is meant a door or a controller that forms the context for executing a command. [[Triggers]] of the types 'Mobile action from site’ and 'External request' do not provide one, and may therefore only execute commands that are origin independent.

All other types of triggers provide an origin and may thus execute both origin independent and origin dependent commands.

== Origin independent commands ==

Origin independent commands always operate on the same door(s) / controller(s) / external target(s) regardless of how or from where the command is triggered. An example of an origin independent command could be to always unlock the same two doors.

=== Perform: On doors ===

Choose the command to be executed and the door(s) to operate on.

The available commands are:
* Grant access
* Override to blocked
* Override to double locked
* Override to locked
* Override to unlocked
* Release override

[[File:command-independent-doors.png|Independent command on doors]]

If ''All doors'' is selected the command will be performed on all of the doors in the [[Delegation|system]].

=== Perform: On controllers ===

Choose the command to be executed and the controller(s) to operate on.

The available commands are the ones that have been defined for ''Origin port output'' (see the section on Origin dependent commands below).

[[File:command-independent-controllers.png|Independent command on controllers]]

If ''All controllers'' is selected the command will be performed on all of the controllers in the [[Delegation|system]].

=== Perform: Externally ===

Construct the API call to be performed by choosing the http method (GET/PUT/POST) and the body of the message.

[[File:command-independent-externally.png|Independent command externally]]

=== Perform: Independent sequence ===

A list of origin independent commands to be executed in a given order. Note that if one command fails, the sequence will be terminated.

[[File:command-independent-sequence.png|Independent command sequence]]

== Origin dependent commands ==

For origin dependent commands, it matters ''from where'' the command is triggered. The door or controller on which the command operates is dependent on the ''origin'' of the trigger.

One example of an origin dependent command is to unlock a door by entering a special code on its associated reader.

An origin is either a door or a controller. Given a door origin, a command that requires a controller, when executed, will be applied on the controller of the door. Given a controller origin, a command that requires a door, when executed, will be applied on each of the doors of the controller.

=== Perform: Native door command ===

Door commands are "native", i.e. are already available in the system, so there is no need to define them before they can be invoked by a trigger or included in other commands.

The native door commands are:
* Grant access
* Override to blocked
* Override to double locked
* Override to locked
* Override to unlocked
* Release override

=== Perform: Origin port output ===

Select the target output port and the action that should be performed.

Note that not all controllers have all IO ports (e.g. Axis A1001 only has IO1 and IO2) so it is necessary to know which type of controller that will be used when specifying the output port of the command. It is also necessary to [[A1001_settings#IO_port_settings|configure the IO ports of the controller]].

The available actions are:
* Activate
* Deactivate
* Pulse

For Pulse, it is possible to set the pulse length in seconds.

[[File:command-dependent-port.png|Dependent command port output]]

=== Perform: Sequence applied on origin ===

A list of commands of any type to be executed in a given order. The origin will be used for any origin dependent commands in the list.

[[File:command-dependent-sequence.png|Dependent command sequence]]

Note that if one command fails, the sequence will be terminated.

== Performing commands from the administrator GUI ==

=== Origin independent commands ===

Origin independent commands can be performed from their detail page:

[[File:perform-command-independent.png|border|Perform independent command]]

=== Native door commands ===

Native door commands can be performed from a door detail page, where they are called ''Actions''.

[[File:perform-door-actions.png|border|Perform door actions]]

=== Origin port commands ===

Origin port output commands can be performed from a controller detail page (if the controller has a matching output port configured).

[[File:perform-origin-port-commands.png|border|Perform origin port commands]]

=== Sequence applied on origin ===

A sequence of commands of which at least one is origin dependent can be launched from either a door detail page or a controller detail page.

[[File:perform-sequence-on-origin.png|border|Perform sequence applied on origin commands]]

Given a door origin, a command that requires a controller, when executed, will be applied on the controller of the door. Given a controller origin, a command that requires a door, when executed, will be applied on each of the doors of the controller.

Commands

2026-02-17T15:30:46Z

Telcredstaff: /* Perform: On controllers */

== Overview ==

A ''command'' is one or more predefined actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]] being activated.

Some use cases for commands include:
* Perform an action simultaneously on a set of doors, e.g. block all doors in a section of the building to achieve a "lockdown".
* Interact with an external system (e.g. arm or disarm an intrusion detection system or turn on the lights).
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule).

=== Origin dependency for commands and relevance for triggers ===

With ''origin'' is meant a door or a controller that forms the context for executing a command. [[Triggers]] of the types 'Mobile action from site’ and 'External request' do not provide one, and may therefore only execute commands that are origin independent.

All other types of triggers provide an origin and may thus execute both origin independent and origin dependent commands.

== Origin independent commands ==

Origin independent commands always operate on the same door(s) / controller(s) / external target(s) regardless of how or from where the command is triggered. An example of an origin independent command could be to always unlock the same two doors.

=== Perform: On doors ===

Choose the command to be executed and the door(s) to operate on.

The available commands are:
* Grant access
* Override to blocked
* Override to double locked
* Override to locked
* Override to unlocked
* Release override

[[File:command-independent-doors.png|Independent command on doors]]

If ''All doors'' is selected the command will be performed on all of the doors in the [[Delegation|organization]].

=== Perform: On controllers ===

Choose the command to be executed and the controller(s) to operate on.

The available commands are the ones that have been defined for ''Origin port output'' (see the section on Origin dependent commands below).

[[File:command-independent-controllers.png|Independent command on controllers]]

If ''All controllers'' is selected the command will be performed on all of the controllers in the [[Delegation|system]].

=== Perform: Externally ===

Construct the API call to be performed by choosing the http method (GET/PUT/POST) and the body of the message.

[[File:command-independent-externally.png|Independent command externally]]

=== Perform: Independent sequence ===

A list of origin independent commands to be executed in a given order. Note that if one command fails, the sequence will be terminated.

[[File:command-independent-sequence.png|Independent command sequence]]

== Origin dependent commands ==

For origin dependent commands, it matters ''from where'' the command is triggered. The door or controller on which the command operates is dependent on the ''origin'' of the trigger.

One example of an origin dependent command is to unlock a door by entering a special code on its associated reader.

An origin is either a door or a controller. Given a door origin, a command that requires a controller, when executed, will be applied on the controller of the door. Given a controller origin, a command that requires a door, when executed, will be applied on each of the doors of the controller.

=== Perform: Native door command ===

Door commands are "native", i.e. are already available in the system, so there is no need to define them before they can be invoked by a trigger or included in other commands.

The native door commands are:
* Grant access
* Override to blocked
* Override to double locked
* Override to locked
* Override to unlocked
* Release override

=== Perform: Origin port output ===

Select the target output port and the action that should be performed.

Note that not all controllers have all IO ports (e.g. Axis A1001 only has IO1 and IO2) so it is necessary to know which type of controller that will be used when specifying the output port of the command. It is also necessary to [[A1001_settings#IO_port_settings|configure the IO ports of the controller]].

The available actions are:
* Activate
* Deactivate
* Pulse

For Pulse, it is possible to set the pulse length in seconds.

[[File:command-dependent-port.png|Dependent command port output]]

=== Perform: Sequence applied on origin ===

A list of commands of any type to be executed in a given order. The origin will be used for any origin dependent commands in the list.

[[File:command-dependent-sequence.png|Dependent command sequence]]

Note that if one command fails, the sequence will be terminated.

== Performing commands from the administrator GUI ==

=== Origin independent commands ===

Origin independent commands can be performed from their detail page:

[[File:perform-command-independent.png|border|Perform independent command]]

=== Native door commands ===

Native door commands can be performed from a door detail page, where they are called ''Actions''.

[[File:perform-door-actions.png|border|Perform door actions]]

=== Origin port commands ===

Origin port output commands can be performed from a controller detail page (if the controller has a matching output port configured).

[[File:perform-origin-port-commands.png|border|Perform origin port commands]]

=== Sequence applied on origin ===

A sequence of commands of which at least one is origin dependent can be launched from either a door detail page or a controller detail page.

[[File:perform-sequence-on-origin.png|border|Perform sequence applied on origin commands]]

Given a door origin, a command that requires a controller, when executed, will be applied on the controller of the door. Given a controller origin, a command that requires a door, when executed, will be applied on each of the doors of the controller.

Commands

2026-02-17T15:29:17Z

Telcredstaff: /* Origin dependency for commands and relevance for triggers */

== Overview ==

A ''command'' is one or more predefined actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]] being activated.

Some use cases for commands include:
* Perform an action simultaneously on a set of doors, e.g. block all doors in a section of the building to achieve a "lockdown".
* Interact with an external system (e.g. arm or disarm an intrusion detection system or turn on the lights).
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule).

=== Origin dependency for commands and relevance for triggers ===

With ''origin'' is meant a door or a controller that forms the context for executing a command. [[Triggers]] of the types 'Mobile action from site’ and 'External request' do not provide one, and may therefore only execute commands that are origin independent.

All other types of triggers provide an origin and may thus execute both origin independent and origin dependent commands.

== Origin independent commands ==

Origin independent commands always operate on the same door(s) / controller(s) / external target(s) regardless of how or from where the command is triggered. An example of an origin independent command could be to always unlock the same two doors.

=== Perform: On doors ===

Choose the command to be executed and the door(s) to operate on.

The available commands are:
* Grant access
* Override to blocked
* Override to double locked
* Override to locked
* Override to unlocked
* Release override

[[File:command-independent-doors.png|Independent command on doors]]

If ''All doors'' is selected the command will be performed on all of the doors in the [[Delegation|organization]].

=== Perform: On controllers ===

Choose the command to be executed and the controller(s) to operate on.

The available commands are the ones that have been defined for ''Origin port output'' (see the section on Origin dependent commands below).

[[File:command-independent-controllers.png|Independent command on controllers]]

If ''All controllers'' is selected the command will be performed on all of the controllers in the [[Delegation|organization]].

=== Perform: Externally ===

Construct the API call to be performed by choosing the http method (GET/PUT/POST) and the body of the message.

[[File:command-independent-externally.png|Independent command externally]]

=== Perform: Independent sequence ===

A list of origin independent commands to be executed in a given order. Note that if one command fails, the sequence will be terminated.

[[File:command-independent-sequence.png|Independent command sequence]]

== Origin dependent commands ==

For origin dependent commands, it matters ''from where'' the command is triggered. The door or controller on which the command operates is dependent on the ''origin'' of the trigger.

One example of an origin dependent command is to unlock a door by entering a special code on its associated reader.

An origin is either a door or a controller. Given a door origin, a command that requires a controller, when executed, will be applied on the controller of the door. Given a controller origin, a command that requires a door, when executed, will be applied on each of the doors of the controller.

=== Perform: Native door command ===

Door commands are "native", i.e. are already available in the system, so there is no need to define them before they can be invoked by a trigger or included in other commands.

The native door commands are:
* Grant access
* Override to blocked
* Override to double locked
* Override to locked
* Override to unlocked
* Release override

=== Perform: Origin port output ===

Select the target output port and the action that should be performed.

Note that not all controllers have all IO ports (e.g. Axis A1001 only has IO1 and IO2) so it is necessary to know which type of controller that will be used when specifying the output port of the command. It is also necessary to [[A1001_settings#IO_port_settings|configure the IO ports of the controller]].

The available actions are:
* Activate
* Deactivate
* Pulse

For Pulse, it is possible to set the pulse length in seconds.

[[File:command-dependent-port.png|Dependent command port output]]

=== Perform: Sequence applied on origin ===

A list of commands of any type to be executed in a given order. The origin will be used for any origin dependent commands in the list.

[[File:command-dependent-sequence.png|Dependent command sequence]]

Note that if one command fails, the sequence will be terminated.

== Performing commands from the administrator GUI ==

=== Origin independent commands ===

Origin independent commands can be performed from their detail page:

[[File:perform-command-independent.png|border|Perform independent command]]

=== Native door commands ===

Native door commands can be performed from a door detail page, where they are called ''Actions''.

[[File:perform-door-actions.png|border|Perform door actions]]

=== Origin port commands ===

Origin port output commands can be performed from a controller detail page (if the controller has a matching output port configured).

[[File:perform-origin-port-commands.png|border|Perform origin port commands]]

=== Sequence applied on origin ===

A sequence of commands of which at least one is origin dependent can be launched from either a door detail page or a controller detail page.

[[File:perform-sequence-on-origin.png|border|Perform sequence applied on origin commands]]

Given a door origin, a command that requires a controller, when executed, will be applied on the controller of the door. Given a controller origin, a command that requires a door, when executed, will be applied on each of the doors of the controller.

Triggers

2026-02-17T15:23:29Z

Telcredstaff: /* Notifications and commands */

Using ''triggers'', it is possible to specify conditions that, when met, should send a [[Notifications|notification]], start a [[Commands|command]], or both.

== Trigger types and activation ==

=== Event ===

A trigger of type ''Event'' is activated when a matching event is received in the [[Events|event log]].

[[File:create-trigger-event.png|border|Create trigger for events]]

=== Reader input ===

A trigger of type ''Reader input'' is activated when a user enters a pre-defined code on an access control reader. Codes are always prefixed with a * (e.g. *112).

[[File:activate-trigger-reader.png|border|Activate trigger for readers]]

It is possible to require authentication to activate the trigger. If authentication is required, it is necessary to specify:
* The authentication method (card or personal PIN)
* Whether to block the card reader before presenting the authentication credential. This is to prevent the door from unlocking or even opening (especially if the door opens automatically). If 'Block access' is set to ''Yes'', the card reader will flash to indicate that the reader has been blocked and is ready to accept the credential. The correct procedure for the end user then becomes:
# Enter activation code
# Wait for the reader to flash (to indicate that the reader has been blocked)
# Present the credential (swipe card or enter PIN)
* Allowed [[Roles|roles]], i.e. which roles should be allowed to activate the trigger.

==== User feedback ====

All readers behave a little differently, but in general this is what should be expected.

===== No authentication credential required =====

# Enter the activation code (e.g. *111).
# Wait for a blinking "success indicator" (will blink for approx. two seconds). The success indicator indicates that the command completed successfully. If the success indicator is not displayed, the command failed to complete all of its actions.

===== Authentication credential required =====

# Enter the activation code (e.g. *111).
# Wait for the reader to start blinking (can take a few seconds). This means that the reader has been temporarily blocked and is ready to receive the authentication credential (i.e. user PIN or card) without granting access.
# Wait for a blinking "success indicator" (will blink for approx two seconds). The success indicator indicates that the command completed successfully. If the success indicator is not displayed, the command failed to complete all of its actions.

=== Mobile action ===

A trigger of type ''Mobile action'' is activated from the mobile app [[Telcred Personal]]. It is necessary to specify whether the origin is by ''Site'' or by ''Door''. This determines if the trigger will be displayed on the Site detail page or on the respective page of the individual doors. It can also have consequences for what the trigger does, in case the trigger invokes a command (see further the section on independent commands vs. origin dependent commands in the [[Commands|commands]] documentation). Just as for ''Reader input'' with authentication, it is necessary to specify which [[Roles|roles]] are allowed to activate the trigger.

[[File:activate-trigger-remote.png|border|Activate remote trigger]]

=== IO port activity ===

A trigger of type ''IO port activity'' is activated when an input port on a controller changes state. It is necessary to specify which input port and transition should activate the trigger.

[[File:activate-trigger-ioport.png|Activate IO port trigger]]

=== External request ===

A trigger of type ''External request'' is activated when the Telcred Access Manager service receives an https GET or POST request on a specified "secret" URL, which is automatically generated by the Telcred service.

[[File:activate-trigger-external-request.png|Activate External request trigger]]

== Optional restrictions ==

It is possible to restrict a trigger with regards to:
* When the trigger can be activated
* Which events or actions can activate the trigger

The options for restricting the trigger depend on the trigger type and possibly also on choices made regarding the trigger activation. For example, for a trigger of type ''Event'', the available restrictions will depend on which event(s) activate the trigger. An ''Access granted'' event can be restricted with regards to time door, user, and method:

[[File:trigger-restrictions-event-access-granted.png|Restrictions for Access granted event]]

On the other hand, a ''Controller offline'' event can only be restricted with regards to time and controller:

[[File:trigger-restrictions-event-controller offline.png|Restrictions for Controller offline event]]

Restrictions that do not apply to all of the activation conditions will not be displayed. For example, if both ''Access granted'' and ''Controller offline'' are selected as activation conditions for a trigger of type ''Event'', it will only be possible to restrict the trigger with regards to time since no event contains attributes for both door and controller. In this case, it may be necessary to create two separate triggers - each with its own restrictions.

[[File:trigger-restrictions-access-mixed.png|Restrictions for mixed door and controller events]]

== Notifications and commands ==

The final step of creating a trigger is to specify what should happen when the trigger is activated. The same trigger can invoke both notifications and [[Commands|commands]]. For notifications, it is necessary to specify the [[Recipients|recipient(s)]].

[[file:recipients.png|border|Recipients]]

Commands are divided into ''Origin independent'' and ''Origin dependent''. The two categories are explained in more detail in the documentation for [[Commands|commands]], but in short an origin independent command will always have the same effect, regardless from where it is triggered, while an origin dependent command takes the origin as an input (e.g. perform ''Override to unlocked'' on the door where the trigger is entered on the reader or activate an output port on the controller of the door where the trigger is entered).

[[file:commands.png|border|Commands]]

Doors

2025-05-15T13:00:17Z

Telcredstaff: /* Actions */

== Settings ==

On the door detail page, the administrator can see and change settings relevant to the individual door. The ''door name'' cannot be changed from here as it is defined in the [[Door configs|door config]]. The settings which are possible to change are:
* ''Notes''. Optional
* ''Door groups''. Optional. For more information on door groups, see [[Door groups|this page]].
* ''Always require PIN''. What the label says. If set to 'Yes', this door can only be opened with card + PIN, even if a user has the the 'card only' privilege for the door. A common use case for this setting is to prevent tenants from giving users access to entrances without requiring a PIN.
* ''Unlocked during''. The door will be unlocked according to a schedule (e.g. weekdays between 09.00 and 17.00). If the door has two locks, both will be unlocked.
* ''Lock 2 unlocked during''. Allows to unlock only the second lock according to a schedule (typically a night lock / motor lock).
* ''Advanced settings / Return to schedule at''. If specified, the door will end a "soft override" and return to schedule at this time. A common use case for this setting is to make sure to not forget returning a door to schedule that has been set to unlocked via soft override during the day.

== Status ==

Four statuses are displayed in the right-hand column for a door:
* Connection
* Lock mode
* Lock state
* Door state

Possible values for ''Connection'' are:
* Online
* Offline
* Incomplete configuration. This means that the controller is not fully configured yet and has never been online.
* Ready to connect. This means that the controller is fully configured and ready to be connected to the Telcred service.
* Failing. This means that the controller is online, but is having problems to sync with the Telcred service. If this happens it is necessary to reset the controller.

Lock mode is what the lock is expected to be when the door is at rest. It is the result of combining (1) schedule override if any, (2) unlock schedules if any, and (3) the number of locks that the door is configured with. An example of when the door is not at rest is when access has been granted. If the door is locked and access is granted, then the lock will become unlocked during the time of the access but the lock mode will remain “Locked”. Possible values for ''Lock mode'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Blocked. The door is locked and grant access is prevented, even with a valid credential.

Lock state is the state indicated by the latest related event received from the controller. If the door is locked, but access is granted, lock state will change during the time of the access. Possible values for ''Lock state'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Unknown. It is not possible to determine the lock state, e.g. because the controller has not been configured yet.

Possible values for ''Door state'' are:
* Open
* Closed
* Unknown

If the door has no door monitor, the door state will always be unknown. It could also be unknown due to the fact that the controller is currently offline.

== Actions ==

It is possible for an administrator, or officer, to ''Grant access'' on a door. This is equivalent to presenting a valid credential to the reader (or using one of the mobile access methods). The door will unlock for the time determined by the ''Access time'' setting, an alert will be triggered if the door is open longer than the time defined by the ''Open too long alarm'' setting, etc. In the ''Events'' log, the ''Method'' will be recorded as ''Officer'' and the officer username will be displayed.

A second group of actions have to do with overriding the schedule(s) that determine when the door's lock(s) should unlock. It is possible to override whatever lock state the door is in to one of:
* Unlocked
* Locked
* Double locked
* Blocked

Override exists in two variants: hard and soft. A hard override will remain in force until the administrator presses ''Return to schedule''. A soft override, on the other hand, will automatically return to schedule the next time the door's schedule changes.

Note: If the door has a wireless lock from [[SimonsVoss SmartIntego]] and it happens to be offline while the Axis controller it is connected to is online, an action may be reported as successful even if did not have the desired effect on the physical lock. More information about this scenario can be found [[Offline wireless locks|here]].

== Commands ==

In the lower part of the right-hand column it is possible to perform user defined origin dependent [[Commands]].

== Validating access ==

At the bottom of the page, there is a link that lets you [[Validating access|check who has access to the door]].

Doors

2025-02-24T12:45:13Z

Telcredstaff: /* Settings */

== Settings ==

On the door detail page, the administrator can see and change settings relevant to the individual door. The ''door name'' cannot be changed from here as it is defined in the [[Door configs|door config]]. The settings which are possible to change are:
* ''Notes''. Optional
* ''Door groups''. Optional. For more information on door groups, see [[Door groups|this page]].
* ''Always require PIN''. What the label says. If set to 'Yes', this door can only be opened with card + PIN, even if a user has the the 'card only' privilege for the door. A common use case for this setting is to prevent tenants from giving users access to entrances without requiring a PIN.
* ''Unlocked during''. The door will be unlocked according to a schedule (e.g. weekdays between 09.00 and 17.00). If the door has two locks, both will be unlocked.
* ''Lock 2 unlocked during''. Allows to unlock only the second lock according to a schedule (typically a night lock / motor lock).
* ''Advanced settings / Return to schedule at''. If specified, the door will end a "soft override" and return to schedule at this time. A common use case for this setting is to make sure to not forget returning a door to schedule that has been set to unlocked via soft override during the day.

== Status ==

Four statuses are displayed in the right-hand column for a door:
* Connection
* Lock mode
* Lock state
* Door state

Possible values for ''Connection'' are:
* Online
* Offline
* Incomplete configuration. This means that the controller is not fully configured yet and has never been online.
* Ready to connect. This means that the controller is fully configured and ready to be connected to the Telcred service.
* Failing. This means that the controller is online, but is having problems to sync with the Telcred service. If this happens it is necessary to reset the controller.

Lock mode is what the lock is expected to be when the door is at rest. It is the result of combining (1) schedule override if any, (2) unlock schedules if any, and (3) the number of locks that the door is configured with. An example of when the door is not at rest is when access has been granted. If the door is locked and access is granted, then the lock will become unlocked during the time of the access but the lock mode will remain “Locked”. Possible values for ''Lock mode'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Blocked. The door is locked and grant access is prevented, even with a valid credential.

Lock state is the state indicated by the latest related event received from the controller. If the door is locked, but access is granted, lock state will change during the time of the access. Possible values for ''Lock state'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Unknown. It is not possible to determine the lock state, e.g. because the controller has not been configured yet.

Possible values for ''Door state'' are:
* Open
* Closed
* Unknown

If the door has no door monitor, the door state will always be unknown. It could also be unknown due to the fact that the controller is currently offline.

== Actions ==

It is possible for an administrator, or officer, to ''Grant access'' on a door. This is equivalent to presenting a valid credential to the reader (or using one of the mobile access methods). The door will unlock for the time determined by the ''Access time'' setting, an alert will be triggered if the door is open longer than the time defined by the ''Open too long alarm'' setting, etc. In the ''Events'' log, the ''Method'' will be recorded as ''Officer'' and the officer username will be displayed.

A second group of actions have to do with overriding the schedule(s) that determine when the door's lock(s) should unlock. It is possible to override whatever lock state the door is in to one of:
* Unlocked
* Locked
* Double locked
* Blocked

A door where ''Override schedule'' has been set will stay in this state until the administrator presses ''Return to schedule''. When this happens the door will switch back to whatever lock state it should have been in at that time according to the schedule(s) defined for ''Unlock'' and ''Unlock lock 2 only''.

Note: If the door has a wireless lock from [[SimonsVoss SmartIntego]] and it happens to be offline while the Axis controller it is connected to is online, an action may be reported as successful even if did not have the desired effect on the physical lock. More information about this scenario can be found [[Offline wireless locks|here]].

== Commands ==

In the lower part of the right-hand column it is possible to perform user defined origin dependent [[Commands]].

== Validating access ==

At the bottom of the page, there is a link that lets you [[Validating access|check who has access to the door]].

Doors

2025-02-24T12:43:37Z

Telcredstaff: /* Settings */

== Settings ==

On the door detail page, the administrator can see and change settings relevant to the individual door. The ''door name'' cannot be changed from here as it is defined in the [[Door configs|door config]]. The settings which are possible to change are:
* ''Notes''. Optional
* ''Door groups''. Optional. For more information on door groups, see [[Door groups|this page]].
* ''Always require PIN''. What the label says. If set to 'Yes', this door can only be opened with card + PIN, even if a user has the the 'card only' privilege for the door. A common use case for this setting is to prevent tenants from giving users access to entrances without requiring a PIN.
* ''Unlocked during''. The door will be unlocked according to a schedule (e.g. weekdays between 09.00 and 17.00). If the door has two locks, both will be unlocked.
* ''Lock 2 unlocked during''. Allows to unlock only the second lock according to a schedule (typically a night lock / motor lock).
* ''Advanced settings / Return to schedule at''. If specified, the door will end a "soft override" and return to schedule at this time. A common use case for this setting is to make sure that a door that has been set to unlocked via soft override is not forgotten in the evening, so that it remains unlocked the whole night.

== Status ==

Four statuses are displayed in the right-hand column for a door:
* Connection
* Lock mode
* Lock state
* Door state

Possible values for ''Connection'' are:
* Online
* Offline
* Incomplete configuration. This means that the controller is not fully configured yet and has never been online.
* Ready to connect. This means that the controller is fully configured and ready to be connected to the Telcred service.
* Failing. This means that the controller is online, but is having problems to sync with the Telcred service. If this happens it is necessary to reset the controller.

Lock mode is what the lock is expected to be when the door is at rest. It is the result of combining (1) schedule override if any, (2) unlock schedules if any, and (3) the number of locks that the door is configured with. An example of when the door is not at rest is when access has been granted. If the door is locked and access is granted, then the lock will become unlocked during the time of the access but the lock mode will remain “Locked”. Possible values for ''Lock mode'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Blocked. The door is locked and grant access is prevented, even with a valid credential.

Lock state is the state indicated by the latest related event received from the controller. If the door is locked, but access is granted, lock state will change during the time of the access. Possible values for ''Lock state'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Unknown. It is not possible to determine the lock state, e.g. because the controller has not been configured yet.

Possible values for ''Door state'' are:
* Open
* Closed
* Unknown

If the door has no door monitor, the door state will always be unknown. It could also be unknown due to the fact that the controller is currently offline.

== Actions ==

It is possible for an administrator, or officer, to ''Grant access'' on a door. This is equivalent to presenting a valid credential to the reader (or using one of the mobile access methods). The door will unlock for the time determined by the ''Access time'' setting, an alert will be triggered if the door is open longer than the time defined by the ''Open too long alarm'' setting, etc. In the ''Events'' log, the ''Method'' will be recorded as ''Officer'' and the officer username will be displayed.

A second group of actions have to do with overriding the schedule(s) that determine when the door's lock(s) should unlock. It is possible to override whatever lock state the door is in to one of:
* Unlocked
* Locked
* Double locked
* Blocked

A door where ''Override schedule'' has been set will stay in this state until the administrator presses ''Return to schedule''. When this happens the door will switch back to whatever lock state it should have been in at that time according to the schedule(s) defined for ''Unlock'' and ''Unlock lock 2 only''.

Note: If the door has a wireless lock from [[SimonsVoss SmartIntego]] and it happens to be offline while the Axis controller it is connected to is online, an action may be reported as successful even if did not have the desired effect on the physical lock. More information about this scenario can be found [[Offline wireless locks|here]].

== Commands ==

In the lower part of the right-hand column it is possible to perform user defined origin dependent [[Commands]].

== Validating access ==

At the bottom of the page, there is a link that lets you [[Validating access|check who has access to the door]].

Doors

2025-02-24T12:37:15Z

Telcredstaff:

== Settings ==

On the door detail page, the administrator can see and change settings relevant to the individual door. The ''door name'' cannot be changed from here as it is defined in the [[Door configs|door config]]. The settings which are possible to change are:
* ''Notes''. Optional
* ''Door groups''. Optional. For more information on door groups, see [[Door groups|this page]].
* ''Always require PIN''. What the label says. If set to 'Yes', this door can only be opened with card + PIN, even if a user has the the 'card only' privilege for the door. A common use case for this setting is to prevent tenants from giving users access to entrances without requiring a PIN.
* ''Unlocked during''. The door will be unlocked according to a schedule (e.g. weekdays between 09.00 and 17.00). If the door has two locks, both will be unlocked.
* ''Lock 2 unlocked during''. Allows to unlock only the second lock according to a schedule (typically a night lock / motor lock).

== Status ==

Four statuses are displayed in the right-hand column for a door:
* Connection
* Lock mode
* Lock state
* Door state

Possible values for ''Connection'' are:
* Online
* Offline
* Incomplete configuration. This means that the controller is not fully configured yet and has never been online.
* Ready to connect. This means that the controller is fully configured and ready to be connected to the Telcred service.
* Failing. This means that the controller is online, but is having problems to sync with the Telcred service. If this happens it is necessary to reset the controller.

Lock mode is what the lock is expected to be when the door is at rest. It is the result of combining (1) schedule override if any, (2) unlock schedules if any, and (3) the number of locks that the door is configured with. An example of when the door is not at rest is when access has been granted. If the door is locked and access is granted, then the lock will become unlocked during the time of the access but the lock mode will remain “Locked”. Possible values for ''Lock mode'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Blocked. The door is locked and grant access is prevented, even with a valid credential.

Lock state is the state indicated by the latest related event received from the controller. If the door is locked, but access is granted, lock state will change during the time of the access. Possible values for ''Lock state'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Unknown. It is not possible to determine the lock state, e.g. because the controller has not been configured yet.

Possible values for ''Door state'' are:
* Open
* Closed
* Unknown

If the door has no door monitor, the door state will always be unknown. It could also be unknown due to the fact that the controller is currently offline.

== Actions ==

It is possible for an administrator, or officer, to ''Grant access'' on a door. This is equivalent to presenting a valid credential to the reader (or using one of the mobile access methods). The door will unlock for the time determined by the ''Access time'' setting, an alert will be triggered if the door is open longer than the time defined by the ''Open too long alarm'' setting, etc. In the ''Events'' log, the ''Method'' will be recorded as ''Officer'' and the officer username will be displayed.

A second group of actions have to do with overriding the schedule(s) that determine when the door's lock(s) should unlock. It is possible to override whatever lock state the door is in to one of:
* Unlocked
* Locked
* Double locked
* Blocked

A door where ''Override schedule'' has been set will stay in this state until the administrator presses ''Return to schedule''. When this happens the door will switch back to whatever lock state it should have been in at that time according to the schedule(s) defined for ''Unlock'' and ''Unlock lock 2 only''.

Note: If the door has a wireless lock from [[SimonsVoss SmartIntego]] and it happens to be offline while the Axis controller it is connected to is online, an action may be reported as successful even if did not have the desired effect on the physical lock. More information about this scenario can be found [[Offline wireless locks|here]].

== Commands ==

In the lower part of the right-hand column it is possible to perform user defined origin dependent [[Commands]].

== Validating access ==

At the bottom of the page, there is a link that lets you [[Validating access|check who has access to the door]].

Keys

2025-02-24T12:27:34Z

Telcredstaff:

Creating a key is a shortcut to assign access privileges to a card (or keyfob), PIN code, or URL. It can be very useful for small installations and residential use cases, where administrators typically handle a small number of credentials and doors.

When creating a new key, it is required to give it a name and to specify the credential type. For credential type 'Card', it is then necessary to choose an available card, i.e. a card that has not already been allocated to a user or to another key. For PIN codes and URLs, the system will, instead, generate a random PIN / URL after the administrator presses Save.

Next, you can specify if the key should be ''limited'' or not. If not, the key will be able to open all doors belonging to the relevant [[Delegation|system]] and at any time (just like a mechanical key).

For a limited key, you can select which time it should be valid and which doors it should be able to open.

Just as for devices, it is possible to block a key which will temporarily remove all access privileges from the key.

Finally, it is possible to specify a PIN for the key, for doors that require a PIN.

Doors

2025-01-29T15:44:46Z

Telcredstaff: /* Settings */

== Settings ==

[[File:Door_detail_page.png|border|Door detail page]]

On the door detail page, the administrator can see and change settings relevant to the individual door. The ''door name'' cannot be changed from here as it is defined in the [[Door configs|door config]]. The settings which are possible to change are:
* ''Description''. Optional
* ''Door groups''. Optional. For more information on door groups, see [[Door groups|this page]].
* ''Unlocked during''. The door will be unlocked according to a schedule (e.g. weekdays between 09.00 and 17.00). If the door has two locks, both will be unlocked.
* ''Lock 2 unlocked during''. Allows to unlock only the second lock according to a schedule (typically a night lock / motor lock).
* Always require PIN. What it says. If set to 'Yes', this door can only be opened with card + PIN, even if a user has the the 'card only' privilege for the door.

== Status ==

Four statuses are displayed in the right-hand column for a door:
* Connection
* Lock mode
* Lock state
* Door state

Possible values for ''Connection'' are:
* Online
* Offline
* Incomplete configuration. This means that the controller is not fully configured yet and has never been online.
* Ready to connect. This means that the controller is fully configured and ready to be connected to the Telcred service.
* Failing. This means that the controller is online, but is having problems to sync with the Telcred service. If this happens it is necessary to reset the controller.

Lock mode is what the lock is expected to be when the door is at rest. It is the result of combining (1) schedule override if any, (2) unlock schedules if any, and (3) the number of locks that the door is configured with. An example of when the door is not at rest is when access has been granted. If the door is locked and access is granted, then the lock will become unlocked during the time of the access but the lock mode will remain “Locked”. Possible values for ''Lock mode'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Blocked. The door is locked and grant access is prevented, even with a valid credential.

Lock state is the state indicated by the latest related event received from the controller. If the door is locked, but access is granted, lock state will change during the time of the access. Possible values for ''Lock state'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Unknown. It is not possible to determine the lock state, e.g. because the controller has not been configured yet.

Possible values for ''Door state'' are:
* Open
* Closed
* Unknown

If the door has no door monitor, the door state will always be unknown. It could also be unknown due to the fact that the controller is currently offline.

== Actions ==

It is possible for an administrator, or officer, to ''Grant access'' on a door. This is equivalent to presenting a valid credential to the reader (or using one of the mobile access methods). The door will unlock for the time determined by the ''Access time'' setting, an alert will be triggered if the door is open longer than the time defined by the ''Open too long alarm'' setting, etc. In the ''Events'' log, the ''Method'' will be recorded as ''Officer'' and the officer username will be displayed.

A second group of actions have to do with overriding the schedule(s) that determine when the door's lock(s) should unlock. It is possible to override whatever lock state the door is in to one of:
* Unlocked
* Locked
* Double locked
* Blocked

A door where ''Override schedule'' has been set will stay in this state until the administrator presses ''Return to schedule''. When this happens the door will switch back to whatever lock state it should have been in at that time according to the schedule(s) defined for ''Unlock'' and ''Unlock lock 2 only''.

Note: If the door has a wireless lock from [[SimonsVoss SmartIntego]] and it happens to be offline while the Axis controller it is connected to is online, an action may be reported as successful even if did not have the desired effect on the physical lock. More information about this scenario can be found [[Offline wireless locks|here]].

== Commands ==

In the lower part of the right-hand column it is possible to perform user defined origin dependent [[Commands]].

== Validating access ==

At the bottom of the page, there is a link that lets you [[Validating access|check who has access to the door]].

Doors

2025-01-29T15:44:15Z

Telcredstaff: /* Settings */

== Settings ==

[[File:Door_detail_page.png|border|Door detail page]]

On the door detail page, the administrator can see and change settings relevant to the individual door. The ''door name'' cannot be changed from here as it is defined in the [[Door configs|door config]]. The settings which are possible to change are:
* ''Description''. Optional
* ''Door groups''. Optional. For more information on door groups, see [[Door groups|this page]].
* ''Unlocked during''. The door will be unlocked according to a schedule (e.g. weekdays between 09.00 and 17.00). If the door has two locks, both will be unlocked.
* ''Lock 2 unlocked during''. Allows to unlock only the second lock according to a schedule (typically a night lock / motor lock).
* Always require PIN. What it says. This door can only be opened with card + PIN, even if a user has the the 'card only' privilege for the door.

== Status ==

Four statuses are displayed in the right-hand column for a door:
* Connection
* Lock mode
* Lock state
* Door state

Possible values for ''Connection'' are:
* Online
* Offline
* Incomplete configuration. This means that the controller is not fully configured yet and has never been online.
* Ready to connect. This means that the controller is fully configured and ready to be connected to the Telcred service.
* Failing. This means that the controller is online, but is having problems to sync with the Telcred service. If this happens it is necessary to reset the controller.

Lock mode is what the lock is expected to be when the door is at rest. It is the result of combining (1) schedule override if any, (2) unlock schedules if any, and (3) the number of locks that the door is configured with. An example of when the door is not at rest is when access has been granted. If the door is locked and access is granted, then the lock will become unlocked during the time of the access but the lock mode will remain “Locked”. Possible values for ''Lock mode'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Blocked. The door is locked and grant access is prevented, even with a valid credential.

Lock state is the state indicated by the latest related event received from the controller. If the door is locked, but access is granted, lock state will change during the time of the access. Possible values for ''Lock state'' are:
* Unlocked
* Locked. The door is locked with one lock. If the door has two locks, lock 2 is unlocked.
* Double locked. The door has two locks and both are locked.
* Unknown. It is not possible to determine the lock state, e.g. because the controller has not been configured yet.

Possible values for ''Door state'' are:
* Open
* Closed
* Unknown

If the door has no door monitor, the door state will always be unknown. It could also be unknown due to the fact that the controller is currently offline.

== Actions ==

It is possible for an administrator, or officer, to ''Grant access'' on a door. This is equivalent to presenting a valid credential to the reader (or using one of the mobile access methods). The door will unlock for the time determined by the ''Access time'' setting, an alert will be triggered if the door is open longer than the time defined by the ''Open too long alarm'' setting, etc. In the ''Events'' log, the ''Method'' will be recorded as ''Officer'' and the officer username will be displayed.

A second group of actions have to do with overriding the schedule(s) that determine when the door's lock(s) should unlock. It is possible to override whatever lock state the door is in to one of:
* Unlocked
* Locked
* Double locked
* Blocked

A door where ''Override schedule'' has been set will stay in this state until the administrator presses ''Return to schedule''. When this happens the door will switch back to whatever lock state it should have been in at that time according to the schedule(s) defined for ''Unlock'' and ''Unlock lock 2 only''.

Note: If the door has a wireless lock from [[SimonsVoss SmartIntego]] and it happens to be offline while the Axis controller it is connected to is online, an action may be reported as successful even if did not have the desired effect on the physical lock. More information about this scenario can be found [[Offline wireless locks|here]].

== Commands ==

In the lower part of the right-hand column it is possible to perform user defined origin dependent [[Commands]].

== Validating access ==

At the bottom of the page, there is a link that lets you [[Validating access|check who has access to the door]].

File:Door detail page.png

2025-01-29T15:42:52Z

Telcredstaff: Telcredstaff uploaded a new version of File:Door detail page.png

Main Page

2024-11-11T14:43:04Z

Telcredstaff: /* Example */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, and delegation ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc, and has its own administrators. The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without being dependent on the building's owner.

==== System types ====

There are four types of systems:
* Standard
* Standard with delegation
* Virtual
* Sub-system

A standard system contains all functionality, including hardware configuration, except delegation. A standard system with delegation also provides the opportunity to create Sub-systems and share doors with Virtual systems (see below).

A virtual system does not have any own hardware, but instead gets doors from other systems of type Standard with delegation. A typical use case for a virtual system is an organization where the employees visit many different sites.

Sub-systems also must get their doors from somewhere else, but in this case they can only get doors from the parent system of which they are a part. A typical use case for a Sub-system is a tenant.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a Virtual system, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to a Virtual system, they can manage the two offices together.

Systems and Domains are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards to Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen, the login context is displayed:

* Account name
* Current System
* Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System, and the Administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the Administrator settings, e.g. to change password, expand the menu right next to the currently logged in Administrator.

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege is defined by a combination of:
* one or more doors
* one or more credentials
* an optional schedule

The supported credential types are:
* Card only
* Card + PIN
* PIN only
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-11-11T14:41:17Z

Telcredstaff: /* Account, Systems, and delegation */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, and delegation ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc, and has its own administrators. The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without being dependent on the building's owner.

==== System types ====

There are four types of systems:
* Standard
* Standard with delegation
* Virtual
* Sub-system

A standard system contains all functionality, including hardware configuration, except delegation. A standard system with delegation also provides the opportunity to create Sub-systems and share doors with Virtual systems (see below).

A virtual system does not have any own hardware, but instead gets doors from other systems of type Standard with delegation. A typical use case for a virtual system is an organization where the employees visit many different sites.

Sub-systems also must get their doors from somewhere else, but in this case they can only get doors from the parent system of which they are a part. A typical use case for a Sub-system is a tenant.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a Virtual system, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems and Domains are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards to Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen, the login context is displayed:

* Account name
* Current System
* Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System, and the Administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the Administrator settings, e.g. to change password, expand the menu right next to the currently logged in Administrator.

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege is defined by a combination of:
* one or more doors
* one or more credentials
* an optional schedule

The supported credential types are:
* Card only
* Card + PIN
* PIN only
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-11-11T14:40:39Z

Telcredstaff: /* Account structure and delegation */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, and delegation ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc, and has its own administrators. The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== System types ====

There are four types of systems:
* Standard
* Standard with delegation
* Virtual
* Sub-system

A standard system contains all functionality, including hardware configuration, except delegation. A standard system with delegation also provides the opportunity to create Sub-systems and share doors with Virtual systems (see below).

A virtual system does not have any own hardware, but instead gets doors from other systems of type Standard with delegation. A typical use case for a virtual system is an organization where the employees visit many different sites.

Sub-systems also must get their doors from somewhere else, but in this case they can only get doors from the parent system of which they are a part. A typical use case for a Sub-system is a tenant.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a Virtual system, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems and Domains are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards to Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen, the login context is displayed:

* Account name
* Current System
* Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System, and the Administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the Administrator settings, e.g. to change password, expand the menu right next to the currently logged in Administrator.

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege is defined by a combination of:
* one or more doors
* one or more credentials
* an optional schedule

The supported credential types are:
* Card only
* Card + PIN
* PIN only
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Privileges

2024-10-11T11:11:03Z

Telcredstaff:

In Telcred Access Manager, privileges express access rights. You can think of a privilege as a key that opens one or more doors with one or more specified credentials (e.g. mobile and card + PIN), optionally restricted to times defined by a [[Schedules|schedule]].

The possible credentials are:
* Card only
* Card + PIN
* PIN only
* Mobile remote
* Mobile on site (Open with the Telcred_Personal app when on site, as defined by the GPS coordinates for the site)
* Mobile at door (Open with the Telcred_Personal app by scanning an NFC tag at the door)
* API 1
* API 2

Mobile remote, Mobile on site, and Mobile at door all concern the [[Telcred_Personal|Telcred Personal]] mobile app. Mobile remote allows the user to open from anywhere. Mobile on site allows the user to remote open doors when the user is on site. This is determined by comparing the phone's current GPS position with the coordinates for the site defined in [[Site Manager]]. Mobile at door allows the user to open a door by scanning an NFC tag at the door.

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

To create a new privilege, select ''Privileges'' in the main menu and click ''Add new''.

Start by giving the privilege a meaningful name.

The next parameter is ''type'', and there are two options: "Regular" and "Use whitelist when possible". The whitelist option is only relevant for doors with locks from [[SimonsVoss SmartIntego]] and is further explained [[SmartIntego settings|here]].

Select which credentials should be used. For privileges of type ''Use whitelist where possible'' the only credential type available is ''card only''.

''Active'' can be either ''Always'' or ''Only during...'' (specified by a schedule). For privileges of type ''Use whitelist where possible'' it is not possible to specify a schedule.

Finally, select the door(s) the privilege should be able to open. It is possible to specify the doors that the privilege should open either by including the individual [[Doors|doors]] or one or more [[Door groups|door groups]]. It is perfectly fine to mix individual doors and door groups in the same privilege.

Main Page

2024-10-11T11:07:07Z

Telcredstaff: /* Privileges */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-systems ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards to Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen, the login context is displayed:

* Account name
* Current System
* Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System, and the Administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the Administrator settings, e.g. to change password, expand the menu right next to the currently logged in Administrator.

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege is defined by a combination of:
* one or more doors
* one or more credentials
* an optional schedule

The supported credential types are:
* Card only
* Card + PIN
* PIN only
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-10-11T11:05:54Z

Telcredstaff: /* Account, Systems, Domains, Sub-accounts */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-systems ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards to Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen, the login context is displayed:

* Account name
* Current System
* Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System, and the Administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the Administrator settings, e.g. to change password, expand the menu right next to the currently logged in Administrator.

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:34:36Z

Telcredstaff: /* Systems */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards to Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen, the login context is displayed:

* Account name
* Current System
* Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System, and the Administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the Administrator settings, e.g. to change password, expand the menu right next to the currently logged in Administrator.

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:32:17Z

Telcredstaff: /* Login context */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen, the login context is displayed:

* Account name
* Current System
* Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System, and the Administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the Administrator settings, e.g. to change password, expand the menu right next to the currently logged in Administrator.

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:30:52Z

Telcredstaff: /* List pages and detail pages */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen, the login context is displayed:

* Account name
* Current System
* Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System, and the administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator.

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:29:48Z

Telcredstaff: /* Login context */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen, the login context is displayed:

* Account name
* Current System
* Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System, and the administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator.

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:26:08Z

Telcredstaff: /* Login context */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen, the login context is displayed:

* Account name
* Current System
* Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator.

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:24:30Z

Telcredstaff: /* Login context */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen, the login context is displayed:

* Account name
* Current System
* Logged in Administrator

If you have access to more than one Account, it is possible to switch between them using the dropdown-menu to the right of the Account name. Likewise, if the Account has more than one System (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the Systems, it is possible to switch System using the dropdown-menu to the right of the System name.

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator.

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:19:51Z

Telcredstaff: /* Account */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one System. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:18:08Z

Telcredstaff: /* Sub-systems */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one [[Main Page#Systems|System]]. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent System. Typically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:17:39Z

Telcredstaff: /* Sub-systems */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one [[Main Page#Systems|System]]. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent Systems. Tyupically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:16:58Z

Telcredstaff: /* Systems */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one [[Main Page#Systems|System]]. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have one or more Domains which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent systems. Tyupically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:16:21Z

Telcredstaff: /* Systems */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one [[Main Page#Systems|System]]. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A system can also have Domain which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent systems. Tyupically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:15:56Z

Telcredstaff: /* Account */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one [[Main Page#Systems|System]]. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A systems also has administrators which can have administration rights in System Manager, Access Manager or both.

A system can also have Domain which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent systems. Tyupically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:14:58Z

Telcredstaff: /* Introduction to System Manager */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Sub-systems
* Administrators

=== Account ===

An Account contains at least one [[Main Page#Systems|System]]. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings and administrators.

=== Systems ===

An account has to contain at least one system. Each system has some settings, e.g.:
* Name
* Default time zone
* Max PIN size
* Notifications language

A systems also has administrators which can have administration rights in System Manager, Access Manager or both.

A system can also have Domain which typically represent a physical space that is leased to a a tenant. For each domain, Private Doors, Shared Doors, and Cards can be defined. The current receiver of a domain (a System or Sub-system) will have access to these resources.

For every system, there is a Card Management feature available. This enables an administrator to create and assign cards Domains and Sub-systems.

=== Sub-systems ===

These receive doors and potentially Cards from the parent systems. Tyupically a Sub-system represents a tenant on a site. When the tenant moves out and another moves in the old Sub-system can simply be deleted, ensuring that all old access rights and personally identifiable information is deleted.

=== Administrators ===

Administrators can have both System Management rights in Access Management rights in multiple Systems and Sub-systems.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T19:02:59Z

Telcredstaff: /* Introduction to System Manager */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Account
* Systems
* Domains
* Sub-systems
* Administrators
* API Credentials

=== Account ===

An Account contains at least one [[Main Page#Systems|System]]. A System has underlying Domains and Sub-systems when "delegated administration" is used.

The account also has some settings and administrators.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:58:22Z

Telcredstaff: /* Introduction to System Manager */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Systems
* Sub-systems
* Administrators
* API Credentials

When "delegated administration" is used, the System is assigned System Manager Administrators.

=== Systems ===

An Account contains at least one [[Main Page#Systems|System]]. A System has underlying Domains and Sub-systems when "delegated administration" is used.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:57:47Z

Telcredstaff: /* Introduction to System Manager */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is and available at:

https://system.telcred.com

In System Manager, the following entities are maintained:

* Systems
* Sub-systems
* Administrators
* API Credentials

When "delegated administration" is used, the System is assigned System Manager Administrators.

=== Systems ===

An Account contains at least one [[Main Page#Systems|System]]. A System has underlying Domains and Sub-systems when "delegated administration" is used.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:55:04Z

Telcredstaff: /* Introduction to System Manager */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:54:15Z

Telcredstaff: /* Administration GUIs */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the Account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:53:55Z

Telcredstaff: /* Administration GUIs */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* Account orchestration. Manage:
** Systems
** Domains
** Sub-systems
** Administrators
* Card management for any system in the account

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Systems and Sub-systems)
* Hardware configuration (for Systems)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:49:55Z

Telcredstaff: /* Administrators and capacities */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, and Administrators. Do Card management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:49:20Z

Telcredstaff: /* Administrators and capacities */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, Administrators, Cards management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:49:02Z

Telcredstaff: /* Administrators and capacities */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in Telcred Accress Manager is known as an “Administrator”. These can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, Administrators, Cards management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:48:33Z

Telcredstaff: /* Administrators and capacities */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in the Telcred system is known as an “Administrator”. These can have different ''capacities'' depending on what they should be able to do. The capacities are:

* Account management (Account settings, create and edit Systems and Administrators)
* System management (Create and edit Domains, Sub-systems, Administrators, Cards management)
* Access management (Create and edit Users, Cards, Roles, and Privileges)

An Administrator can simultaneously have capacities across Accounts, Systems, and Sub-systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:46:36Z

Telcredstaff: /* Example */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate company sets up two Systems for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Sub-system) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to System 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in the Telcred system is known as an “Administrator”. These can have different ''capacities'' depending on what they should be able to do. The capacities are:

* System Management (System settings, create and edit Sites and Administrators)
* Site Management (Create and edit Domains, Tenant Systems, Administrators, Cards and transfers)
* Access Management (Create and edit Users, Cards, Roles, Privileges)

An Administrator can simultaneously have capacities across Systems, Sites, and Tenant Systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:41:03Z

Telcredstaff: /* Account structure and delegation */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate owner sets up two Sites for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Tenant System) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to Site 3, they can manage the two offices as one.

Systems, Domains, and Sub-systems are created, organized and maintained in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in the Telcred system is known as an “Administrator”. These can have different ''capacities'' depending on what they should be able to do. The capacities are:

* System Management (System settings, create and edit Sites and Administrators)
* Site Management (Create and edit Domains, Tenant Systems, Administrators, Cards and transfers)
* Access Management (Create and edit Users, Cards, Roles, Privileges)

An Administrator can simultaneously have capacities across Systems, Sites, and Tenant Systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:39:41Z

Telcredstaff: /* Systems, Sites, Domains, Tenant Systems */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Account, Systems, Domains, Sub-accounts ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate owner sets up two Sites for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Tenant System) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to Site 3, they can manage the two offices as one.

[[File:Sites2.png|System and organizations]]

Domains and Tenant Systems are organized and maintained in the Site Manager module included in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in the Telcred system is known as an “Administrator”. These can have different ''capacities'' depending on what they should be able to do. The capacities are:

* System Management (System settings, create and edit Sites and Administrators)
* Site Management (Create and edit Domains, Tenant Systems, Administrators, Cards and transfers)
* Access Management (Create and edit Users, Cards, Roles, Privileges)

An Administrator can simultaneously have capacities across Systems, Sites, and Tenant Systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T18:38:49Z

Telcredstaff: /* Account structure and delegation */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Systems, Sites, Domains, Tenant Systems ===

A Telcred customer account can contain one or more Systems. A system contains doors, users, access rights, schedules, events etc. A system can also contain sub-systems, which contain their own users, access rights, schedules, events, and so on, but the doors come from the parent system.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Systems ====

A System typically represents a building or a group of buildings with a shared facility management. Under the System, Domains and Sub-systems are created and maintained if delegated access management is used. An Account always includes at least one system which is used for configuring the doors that can be allocated to the Domains of the Site.

A System without Domains works as a regular access control system. It can still be connected connect to Domains of other Systems and that way, doors from different Systems can be administered together.

==== Domains ====

Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Sub-system or a System, the doors and privileges of the Domain become available for access administration in the receiving system.

==== Sub-systems ====

Tenants or other user groups, receive their own System or Sub-system, which they can administer on their own.

==== Example ====

A real estate owner sets up two Sites for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Tenant System) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to Site 3, they can manage the two offices as one.

[[File:Sites2.png|System and organizations]]

Domains and Tenant Systems are organized and maintained in the Site Manager module included in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in the Telcred system is known as an “Administrator”. These can have different ''capacities'' depending on what they should be able to do. The capacities are:

* System Management (System settings, create and edit Sites and Administrators)
* Site Management (Create and edit Domains, Tenant Systems, Administrators, Cards and transfers)
* Access Management (Create and edit Users, Cards, Roles, Privileges)

An Administrator can simultaneously have capacities across Systems, Sites, and Tenant Systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T10:35:36Z

Telcredstaff: /* Access control model */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
** Remote
** On site
** At door
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Systems, Sites, Domains, Tenant Systems ===

A Telcred customer account is referred to as a ''System''. For a Telcred System, any number of Sites, holding an unlimited number of Domains and Tenant Systems, can be created. Each Site and Tenant System has its own administrators, users, access rights, cards, events, and doors.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Sites ====

A Site typically represents a building or a group of buildings with a shared facility management. Under the Site, Domains and Tenant Systems are created and maintained if delegated access management is used. A Site always includes a system which is used for configuring the doors that can be allocated to the Domains of the Site.

A Site without underlying Domains works as a regular access control system. It can still connect Domains of other Sites and that way, doors from different Sites can be administered together.

==== Domains ====
Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Tenant System, the doors and privileges of the Domain become available for access administration in the Tenant System.

==== Tenant Systems ====
Tenants or other user groups, receive Tenant Systems, which they can administer on their own.

==== Example ====
A real estate owner sets up two Sites for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Tenant System) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to Site 3, they can manage the two offices as one.

[[File:Sites2.png|System and organizations]]

Domains and Tenant Systems are organized and maintained in the Site Manager module included in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in the Telcred system is known as an “Administrator”. These can have different ''capacities'' depending on what they should be able to do. The capacities are:

* System Management (System settings, create and edit Sites and Administrators)
* Site Management (Create and edit Domains, Tenant Systems, Administrators, Cards and transfers)
* Access Management (Create and edit Users, Cards, Roles, Privileges)

An Administrator can simultaneously have capacities across Systems, Sites, and Tenant Systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T10:33:42Z

Telcredstaff: /* System components */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal & Telcred Home)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Systems, Sites, Domains, Tenant Systems ===

A Telcred customer account is referred to as a ''System''. For a Telcred System, any number of Sites, holding an unlimited number of Domains and Tenant Systems, can be created. Each Site and Tenant System has its own administrators, users, access rights, cards, events, and doors.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Sites ====

A Site typically represents a building or a group of buildings with a shared facility management. Under the Site, Domains and Tenant Systems are created and maintained if delegated access management is used. A Site always includes a system which is used for configuring the doors that can be allocated to the Domains of the Site.

A Site without underlying Domains works as a regular access control system. It can still connect Domains of other Sites and that way, doors from different Sites can be administered together.

==== Domains ====
Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Tenant System, the doors and privileges of the Domain become available for access administration in the Tenant System.

==== Tenant Systems ====
Tenants or other user groups, receive Tenant Systems, which they can administer on their own.

==== Example ====
A real estate owner sets up two Sites for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Tenant System) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to Site 3, they can manage the two offices as one.

[[File:Sites2.png|System and organizations]]

Domains and Tenant Systems are organized and maintained in the Site Manager module included in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in the Telcred system is known as an “Administrator”. These can have different ''capacities'' depending on what they should be able to do. The capacities are:

* System Management (System settings, create and edit Sites and Administrators)
* Site Management (Create and edit Domains, Tenant Systems, Administrators, Cards and transfers)
* Access Management (Create and edit Users, Cards, Roles, Privileges)

An Administrator can simultaneously have capacities across Systems, Sites, and Tenant Systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T10:33:03Z

Telcredstaff: /* System components */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal, Telcred Home, Customer Apps)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Systems, Sites, Domains, Tenant Systems ===

A Telcred customer account is referred to as a ''System''. For a Telcred System, any number of Sites, holding an unlimited number of Domains and Tenant Systems, can be created. Each Site and Tenant System has its own administrators, users, access rights, cards, events, and doors.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Sites ====

A Site typically represents a building or a group of buildings with a shared facility management. Under the Site, Domains and Tenant Systems are created and maintained if delegated access management is used. A Site always includes a system which is used for configuring the doors that can be allocated to the Domains of the Site.

A Site without underlying Domains works as a regular access control system. It can still connect Domains of other Sites and that way, doors from different Sites can be administered together.

==== Domains ====
Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Tenant System, the doors and privileges of the Domain become available for access administration in the Tenant System.

==== Tenant Systems ====
Tenants or other user groups, receive Tenant Systems, which they can administer on their own.

==== Example ====
A real estate owner sets up two Sites for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Tenant System) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to Site 3, they can manage the two offices as one.

[[File:Sites2.png|System and organizations]]

Domains and Tenant Systems are organized and maintained in the Site Manager module included in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in the Telcred system is known as an “Administrator”. These can have different ''capacities'' depending on what they should be able to do. The capacities are:

* System Management (System settings, create and edit Sites and Administrators)
* Site Management (Create and edit Domains, Tenant Systems, Administrators, Cards and transfers)
* Access Management (Create and edit Users, Cards, Roles, Privileges)

An Administrator can simultaneously have capacities across Systems, Sites, and Tenant Systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T10:32:29Z

Telcredstaff: /* System components */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager & System Manager)
#* Apps (Telcred Personal, Telcred Home, Telcred Office, Customer Apps)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Systems, Sites, Domains, Tenant Systems ===

A Telcred customer account is referred to as a ''System''. For a Telcred System, any number of Sites, holding an unlimited number of Domains and Tenant Systems, can be created. Each Site and Tenant System has its own administrators, users, access rights, cards, events, and doors.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Sites ====

A Site typically represents a building or a group of buildings with a shared facility management. Under the Site, Domains and Tenant Systems are created and maintained if delegated access management is used. A Site always includes a system which is used for configuring the doors that can be allocated to the Domains of the Site.

A Site without underlying Domains works as a regular access control system. It can still connect Domains of other Sites and that way, doors from different Sites can be administered together.

==== Domains ====
Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Tenant System, the doors and privileges of the Domain become available for access administration in the Tenant System.

==== Tenant Systems ====
Tenants or other user groups, receive Tenant Systems, which they can administer on their own.

==== Example ====
A real estate owner sets up two Sites for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Tenant System) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to Site 3, they can manage the two offices as one.

[[File:Sites2.png|System and organizations]]

Domains and Tenant Systems are organized and maintained in the Site Manager module included in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in the Telcred system is known as an “Administrator”. These can have different ''capacities'' depending on what they should be able to do. The capacities are:

* System Management (System settings, create and edit Sites and Administrators)
* Site Management (Create and edit Domains, Tenant Systems, Administrators, Cards and transfers)
* Access Management (Create and edit Users, Cards, Roles, Privileges)

An Administrator can simultaneously have capacities across Systems, Sites, and Tenant Systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].

Main Page

2024-09-19T10:31:14Z

Telcredstaff: /* Security */

== Introduction & benefits ==

Telcred Access Manager is a software for physical access control, provided as a cloud-service. The solution is designed to work with IP-connected door controllers, primarily [https://www.axis.com/products/network-door-controllers Network Door Controllers] from [http://www.axis.com/ Axis Communications]. The Axis door controllers can also be extended with wireless locks using either [https://www.smartintego.com/int/home/home/ SimonsVoss SmartIntego] or [https://www.assaabloy.com/en/com/solutions/technology-platforms/aperio/ Assa Aperio].

This online documentation describes the main features of the solution. It is aimed at new customers and partners as a general introduction.

Some of the benefits of Telcred Access Manager include:
* Cloud-based service
* Simple and secure connection of door controllers
* Mobile access with smartphone app or URL
* Simple access for visitors
* Delegated administration
* Powerful framework for custom actions
* Strong security
* API for external integrations

=== Cloud-based service ===

The combination of IP-connected door controllers and a cloud-based service means that the access control system becomes completely ''independent of location''. It does not matter if you have 10 doors in one location or 10 different locations with one door each. Also, you can manage the system from anywhere - inside the same building or from another country.

With a cloud-based service there is ''no need for system maintenance'', i.e. to install upgrades and security patches, do backups, etc. This is all professionally managed by Telcred.

Even if it is a cloud-based service, the Telcred solution ''keeps working during temporary network failures''. All relevant data is stored locally in the door controllers, which only need to be online to receive updates. In other words, users can still open doors, and no event data is lost, even if the network is down. When the door controller comes back online it will automatically sync pending updates and events with the Telcred service.

=== Simple and secure connection ===

Telcred uses the O3C (One-Click-Connection-Component) technology developed by Axis Communications, which makes the door controllers both simple to install and secure. With O3C, door controllers connect to the Telcred service using an encrypted outgoing IP-connection, which means that in most cases there is no need to configure firewalls or routers. After the physical installation, the installer pushes a button on the controller which then automatically downloads the connection settings from an Axis server and immediately uses them to connect to the Telcred service.

=== Mobile access ===

The [[Telcred_Personal|Telcred Personal]] and [[Telcred Home]] apps for iOS and Android can be used to open doors as a complement or alternative to traditional cards and keyfobs. Opening a door with an app typically takes less than a second and can be used to let someone in remotely. If all users can use an app neither cards nor readers are necessary! Using a smartphone instead of a card has the added benefit of better security. Compared to access cards, most people are less likely to lose or lend their phone to someone else or to share their PIN. Another form of mobile access is through a URL for visitors (see directly below).

=== Visitor access ===

A [[Visits|Visit]] allows the administrator to create a PIN and/or URL that can be used to open one or more doors during a specified time, e.g. in connection with a meeting or an event. The PIN is entered on a reader at the door and the URL can be included in e.g. an email to the visitors. When the visitors arrive, they can let themselves in simply by entering the PIN or clicking the URL in their smartphone email application, without having to receive an access card or install an app. PIN and URL are to be considered low security (anyone who has access to the PIN or the URL can open the door), but for many use cases this is an acceptable trade-off for the convenience it provides.

=== Delegation ===

The Telcred system has been designed to be simple to administrate, yet able to handle large and complex installations. A key aspect of the latter is ''delegation''. With the Telcred solution, it is simple to create "virtual systems" where e.g. tenants or sub-contractors can manage their own doors, users, and access rights. Shared doors, e.g. entrance doors, can also be included in a virtual system. It is also possible to share users from one system to another. Delegation is managed through a separate web interface: [[System Manager]].

=== Actions ===

Telcred offers a powerful framework to perform both built-in and custom ''actions'' when a ''trigger'' is activated, e.g. as the result of an event, user input on an access control reader, or activity on a controller input port.

A common action is to send a notification via mail or directly to an external system as an http request. It is also possible to invoke a ''command'', which in turn can e.g. perform actions on a pre-defined set of doors or activate the output port on one or more controllers.

Use cases for actions include:
* Interact with an external alarm system (e.g. arm an intrusion alarm or send a distress signal)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule from their mobile phone)
* Put a building in lockdown (all doors are locked and access control readers are blocked)

=== Security ===

The administrator login, often the weakest point in terms of security, can be configured to use two-factor authentication. Another common security weakness is old firmware. With Telcred Access Manager it is simple to check and upgrade the firmware remotely. All communication between the door controllers and the Telcred cloud-service uses strong encryption and the communication between mobile apps and the cloud service uses strong authentication based on PKI.

=== API for integration ===

Telcred provides a modern REST API which can be used for external integrations. The API covers the complete functionality of the system and can be used to extend another security system, e.g. a video management or alarm system, with access control functionality. It can also be used to integrate e.g. a booking system, a member database, or a workforce management system with the Telcred access control service.

== System components ==

Telcred Access Manager consists of four main components:
# Cloud-based server software
# User interfaces for access administration, configuration and end users
#* Web-based GUIs (Access Manager, Site Manager)
#* Apps (Telcred Personal, Telcred Home, Telcred Office, Customer Apps)
# APIs for integration of GUIs, apps, and 3rd party software
# API for communicating with IP door controllers

[[File:System_components5.png|500px|Telcred system components]]

Currently, The Telcred solution supports [https://www.axis.com/products/network-door-controllers Network Door Controllers] from Axis Communications. One controller can manage one or two doors with electrical locks, and additionally connect:

* up to 16 wireless locks from [[SimonsVoss SmartIntego]] (via a SmartIntego hub connected to the controller over IP)
* up to 8 wireless locks from [[Assa Aperio]] (via an Assa Aperio hub connected to the controller over RS485)

In addition to the Network Door controllers, it is also possible to use the [https://www.axis.com/products/network-io-relay-modules Axis Network I/O Relay Modules]. These products are suitable if there is no need to use cards or PINs (i.e. only mobile access).

* The A9188 Network I/O Relay in combination with a Network Door Controller can be used in elevators to control access to different floors of a building.

== Access control model ==

Below follows a short overview of the access control model in Telcred Access Manager, i.e. how it is determined which devices, or credentials, that can open which doors, when, and how.

A central concept in Telcred's model is that of a ''privilege''. A privilege expresses an access right, i.e. the right to open one or more doors. In addition to the door(s) it opens, a privilege is defined by the credential that needs to be used (e.g. card + PIN) and an optional schedule that determines when it is valid (the default is always). Schedules can be simple, e.g. Monday to Friday from 08.00 to 18.00, or more complex and exclude e.g. yearly public holidays. Currently the different credentials that can be specified for a privilege are:

* Card only
* Card + PIN
* PIN only
* Mobile
* API 1
* API 2

The purpose of API 1 and API 2 are to let an external system request access by supplying the door identity and a credential identifier that could represent e.g. a license plate, a face, or the customer's own smartphone app.

[[File:ac_model3.png|Access Control model]]

Users receive privileges (i.e. access rights) through a ''role''. A role can contain many users and many privileges, and would typically correspond to the access rights for some group of users, e.g. management, cleaning staff, technicians, students, etc. Roles can have a start and end time, during which the assigned privileges are valid for the user(s).

A user can own several devices, e.g. a card and a phone, and each will receive the access rights of its owner. If a device is disconnected from a user it will lose all its access rights and not be able to open any doors.

== Account structure and delegation ==

=== Systems, Sites, Domains, Tenant Systems ===

A Telcred customer account is referred to as a ''System''. For a Telcred System, any number of Sites, holding an unlimited number of Domains and Tenant Systems, can be created. Each Site and Tenant System has its own administrators, users, access rights, cards, events, and doors.

The purpose of this structure is “delegation of access administration”, i.e. to let administrators with direct knowledge of, and responsibility for, their users perform the administration without relying on a centralised administration function. A typical example of where delegation can be useful is an office building with multiple tenants. The delegation functionality allows each tenant to manage their own users and access rights without relying on the building's owner.

==== Sites ====

A Site typically represents a building or a group of buildings with a shared facility management. Under the Site, Domains and Tenant Systems are created and maintained if delegated access management is used. A Site always includes a system which is used for configuring the doors that can be allocated to the Domains of the Site.

A Site without underlying Domains works as a regular access control system. It can still connect Domains of other Sites and that way, doors from different Sites can be administered together.

==== Domains ====
Domains represent spaces such as offices, business premises, apartments, workshops, garages etc. A Domain can contain private doors, shared doors, and shared privileges. By connecting a Domain to a Tenant System, the doors and privileges of the Domain become available for access administration in the Tenant System.

==== Tenant Systems ====
Tenants or other user groups, receive Tenant Systems, which they can administer on their own.

==== Example ====
A real estate owner sets up two Sites for buildings in two different locations and lets the respective Site Manager define Domains representing the spaces being let out to tenants. Upon moving in, each tenant receives their own virtual system (Tenant System) connected to the Domain(s) representing the spaces they are renting. One tenant is renting spaces (Office 2 and Office 5) in two different Sites but by connecting these two Domains to Site 3, they can manage the two offices as one.

[[File:Sites2.png|System and organizations]]

Domains and Tenant Systems are organized and maintained in the Site Manager module included in [[Main Page#Introduction to System Manager|System Manager]].

=== Administrators and capacities ===

A person doing any type of administration in the Telcred system is known as an “Administrator”. These can have different ''capacities'' depending on what they should be able to do. The capacities are:

* System Management (System settings, create and edit Sites and Administrators)
* Site Management (Create and edit Domains, Tenant Systems, Administrators, Cards and transfers)
* Access Management (Create and edit Users, Cards, Roles, Privileges)

An Administrator can simultaneously have capacities across Systems, Sites, and Tenant Systems.

== Administration GUIs ==

[[Main Page#Introduction to System Manager|System Manager]] web GUI
* System orchestration (Sites, Administrators)
* Site Management (Domains, Tenant Systems, Cards)

[[Main Page#Introduction to Access Manager|Access Manager]] web GUI
* Access Management (for Sites and Tenant Systems)
* Configuration (for Sites)

[[Telcred Home]] app
* Access Management for residents

== Introduction to System Manager ==

The System Manager GUI is web-based and available at:

https://system.telcred.com

[[File:System_Manager.png|800px|System Manager]]

In System Manager, the following entities are maintained:

* Sites
* Administrators
* API Credentials

When "delegated administration" is used, the Site is assigned Site Manager Administrators. For these administrators, the module [[Site Manager]] is available in System Manager.

=== Sites ===

A System contains at least one [[Main Page#Sites|Site]]. A Site have underlying Domains and Tenants systems when "delegated administration" is applied. If "delegated administration" is not applied, the Site functions as a regular access control system.

Max PIN Size - the max PIN code length. This will also apply to Tenant Systems of the Site.

==== Assign Administrators ====

* Access Management - Access Management Administrators perform access management and configuration in [[Main Page#Introduction to Access Manager|Access Manager]] for the Site (not underlying Tenant Systems).

* Site Management - Site Manager Administrator manage Domains, Tenant Systems, Leases, and Cards for a Site. Only relevant when "delegated administration" is applied.

=== Administrators ===

Administrators can both have Access Management as well as Site Management capacities. After an Administrator is set up for the first time, the administrator can register at signup.telcred.com. Email is the unique ID of and administrator and signup is only done once.

=== API Credentials ===

API Credentials for integrations. An API Key (password) is generated when a new API Credential is saved.

== Introduction to Access Manager ==

The Access Manager GUI is web-based and available at:

https://access.telcred.com

=== Login context ===

In the top-right of the screen (1), the login context is displayed:

* System name
* Current organization (of a Site or Tenant System)
* Logged in administrator

[[File:Access_manager2.png|800px|Login context]]

If you have access to more than one system, it is possible to switch between them using the dropdown-menu to the right of the system name. Likewise, if the system has more than one organization (see the section on [[Delegation|delegation]]), and the administrator has administration rights in more than one of the organizations, it is possible to switch organizations using the dropdown-menu to the right of the organization name (2).

To access the officer settings, e.g. to change password, expand the menu right next to the currently logged in administrator (3).

More information about the administrator settings can be found [[Administrator settings|here]].

=== Four main menu groups ===

The administrator GUI is divided into four main menu groups:

* [[Main Page#Start|Start]]. The most common options including view status and event log; Manage users, devices, doors, and schedules.
* [[Main Page#Roles|Roles]]. Define roles and privileges. After setting up these, it is possible to validate that the desired result has been achieved, by validating the access for either a user, device, or door. More information about validating access can be found [[Validating access|here]].
* [[Main Page#Actions|Actions]]. Define special rules for what should happen when certain things occur. For example: "Send a notification and activate an IO port if there is a ''Door forced open'' alarm".
* [[Main Page#Configuration|Configuration]]. Manage hardware configuration for doors, door controllers, and hubs.

=== List pages and detail pages ===

In each group a number of ''list pages'' are available from the menu. From the list page it is possible to click an individual item to get to its ''detail page'' where it is possible to view or change detailed information.

# Currently selected list
# Click a list item to see the details
# Number of items in list

[[File:Door_list2.png|800px|List page]]

In the left hand column of the detail page, the item is displayed with its current attributes. In the right hand column there is more information about the current item, such as its current status, available actions, and related items.

[[File:Door_details2.png|800px|Detail page]]

== Administrator GUI menu options ==

=== Start ===

==== Status ====

After successful login, the administrator is presented with an overview page showing:
* Latest alerts
* Doors with issues (offline or failing sync process)

==== 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.

More information about events can be found [[Events|here]].

==== Users ====

Users are the end users of the system that need to be able to open doors. A user can be the owner of one or more cards. Every card that a user owns, will inherit the access rights of its owner. A user can also have mobile access (or not).

In addition to the mandatory name, a user can have several optional attributes that can be used to sort and filter users, e.g. Unique ID and Notes.

A personal PIN can also be set for a user. A privilege can require the entry of a correct PIN to grant access (typically for high security doors or out of office hours). The PIN length is configurable and set by the Site Manager.

More information about users can be found [[Users|here]].

==== Cards ====

Cards can be actual cards or keyfobs. A user can have several cards. They will all inherit the access rights for that user. A card can only belong to one user at a time, but it is possible to reassign a card to a different user.

More information about cards can be found [[Cards|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
* Manually block
* Return to schedule

More information about doors can be found [[Doors|here]].

==== Schedules ====

Schedules are used to:
* Control when a door should be single locked, double locked or unlocked
* Specify when a ''privilege'' is valid
* Specify when a ''visit'' 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 [[Schedules|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), a random PIN, or both. The URL 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. An alternative to the URL is to enter the randomly generated PIN on the reader connected to the door.

It should be noted that ''Visits'' is relatively low security because anybody who has access to the URL or PIN can open the door, and it is not possible to know the identity of the actual person who did the opening.

More information about visits can be found [[Visits|here]].

==== Keys ====

A key is a quick and easy way to let a card or keyfob open one or more doors, without having to define users, roles, and access privileges. It can be especially useful in a residential use case, where an apartment owner typically handles a very small number of keyfobs and doors.

More information about keys can be found [[Keys|here]].

=== Roles ===

==== Roles ====

''Roles'' is how a user gets access rights to doors. A role connects one or more users to one or more privileges. Roles have names and 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 [[Roles|here]].

==== Privileges ====

Privileges express access rights, i.e. the right to open one or more doors. A privilege 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
* Mobile remote
* Mobile on site
* Mobile at door
* API 1
* API 2

More information about privileges can be found [[Privileges|here]].

==== Door groups ====

''Door groups'' are collections of doors. The main purpose of door groups is to make it easy to create privileges / 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 [[Door_groups|here]].

=== Triggers ===

==== Triggers ====

Using triggers, it is possible to specify conditions that, when met, should send a notification, start a command, or both.

There are five types of triggers:
* Event
* Reader input
* Remote action
* IO port activity
* External request

More information about triggers can be found [[Triggers|here]].

==== Recipients ====

Recipients can receive notifications via email, SMS, or "webhook" (http request), when a trigger is activated. While the trigger defines the condition(s) that will result in a notification, the ''Recipient'' specifices the receiver of the information and other conditions related to the delivery (e.g. during which time notifications should be sent).

More information about recipients can be found [[Recipients|here]].

==== Commands ====

A command is a set of one or more actions that can either be performed by an administrator or as a result of a [[Triggers|trigger]]. Some use cases for commands include:
* Perform an action simultaneously on a number of doors, a door group, or a combination (e.g. block all doors in a section of the building to achieve a "lockdown").
* Interact with an external system (e.g. arm or disarm an intrusion detection system)
* Allow end users to perform an action normally only available to administrators (e.g. unlock a door or return it to schedule)

More information about commands can be found [[Commands|here]].

=== Configuration ===

==== Door configs ====

A door config defines the technical settings for a door, e.g. which controller the door is connected to and different settings related to door alarms.

Typically, the door config settings will be done by the installer / integrator and not by the end customer administrator.

More information about door configs can be found [[Door configs|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 [[Controllers|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 [[Hubs|here]].

== Guides & tutorials ==

=== Connect an Axis controller with O3C ===

To connect an Axis Network Door Controller to the Telcred service you need:

* The controller
* An Ethernet connection capable of supplying PoE (Power over Ethernet)
* The MAC address of the controller (printed on the device but called S/N)
* The OAK (Owner Authentication Key). This is a code that is printed on a piece paper that is shipped in the box with the controller. If it has been lost, you can get help with retrieving it from either Axis or Telcred

The minimum steps to create the controller in Telcred Access Manager are:

# Select ''Controllers'' in the main menu and click ''Add new''
# Give the controller a name
# Make sure the ''Connection mode'' is ''O3C'' (this is the default)
# Enter the MAC address and OAK
# Click ''Save''

After a few seconds, the status message at the top of the page should now say ''Ready - Waiting for the controller to initiate connection''. This means that Telcred Access Manager managed to connect to the Axis ''Dispatch server'' and claim this controller.

The final step is to push the ''control button'' on the controller for 1 - 2 seconds:

[[File:Control_button2.png|Control button]]

This will tell the controller to connect to the Axis Dispatch server and download a certificate with all the information it needs in order to connect to the Telcred service in a secure way, which it will try to do immediately after receiving the certificate.

After the controller manages to connect to Telcred Access Manager its status will be updated to ''Online''.

* Detailed information about the A1001 communication settings can be found [[A1001 settings#Connection_settings|here]].
* Detailed information about the A1601 communication settings can be found [[A1601 settings#Connection_settings|here]].

=== Set up a new user & provide him or her with access to a door ===

After a new system has been set up, at least one controller with a reader has been connected, and at least one [[Door configs|door config]] configured and connected to the controller, you are ready to start defining and testing the actual access. The minimum steps to do this are (click the links for more details):

# Create a [[Users|user]]
# Register a new [[Devices|card]] and assign it to the user
# Create a [[Privileges|privilege]]
# Create a [[Roles|role]] linking the user to the privilege

After these steps, the user should be able to access the door with their card. Note that it can take a few seconds before the access rights have been downloaded to the door controller.

== Technical references ==

=== API documentation ===

Virtually everything that can be done through the Telcred GUI can also be done through our APIs. There are three APIs:
* Webhooks API. Used to let another system receive push notifications. The API documentation can be found [https://v1telcredaccessmanagerwebhooks.docs.apiary.io/# here].
* Admin API. Used to do everyday admin tasks, such as managing users, credentials, and access rights. The API documentation can be found [https://v2accessmanageradmin.docs.apiary.io/# here].
* Owner API. Used to e.g. manage organizations and officers. The API documentation can be found [https://ownermanagement.docs.apiary.io/# here].