Open

Technical Manual | TM-20210309-TP-02 iProtect Access / Security | General |

Open

This manual represents the knowledge at the above-mentioned time. TKH security works non-stop to improve her products. For the most recent technical information please contact your consultant or dealer.

Table of content

1 Introduction

This manual describes the functions in iProtect that deal with persons. In iProtect there are different
kinds of persons:

• Card holders

• Employees

• Visitors

• System users

In this document all aspects and features of the first three types of persons are discussed. The System
users are described in a separate manual “iProtect System User & Authorizations”.

1.1 Information structure

All data in iProtect that is directly related to persons is stored in a number of database tables. For the
different types of persons all common information is stored in the PERSON table.
By combining this information with information on access keys, specific information on employees or
specific information on visitors, the complete set of options is obtained for each of these types of
persons.

Figure 1 Structure of person data

The types of person are not exclusive in the iProtect system. This means that an employee can also be
a visitor and that a visitor van also be a card holder, etc.

2 Personal Data

This chapter describes the information that can be defined for all different kinds of persons in the iProtect
system.

Currently, the maximum number of person records in the iProtect database is 1.000.000.

2.1 Person details

Menu | General | Person

2.1.1 General information

In these fields the general information about the person can be entered.
• Surname: This is the only field for a person that is mandatory. It is used to sort the persons in search results. The maximum length is 40 characters.
• Prefix: Maximum length 40 characters
• First name: Maximum length 40 characters
• Address: Maximum length 40 characters
• Postal code: Maximum length 40 characters
• City: Maximum length 40 characters

2.1.2 Photo

A photo can be added to the personal details. By clicking on the photo frame, a pop-up appears that
allows the user to select the image from 2 different sources:

• Network: The image will be loaded over the network from your local workstation. With the
  upload button, the location of the image that will be uploaded can be selected. The checkbox
  Save in list makes it possible to store this image on the iProtect server for later use. With the
  Delete button a photo that was previously attached to this person can be deleted.
  
  

• Server: The image will be loaded from the iProtect server. A selection can be made from
  previously saved images on the server.

The following image formats are supported:
• JPG
• PNG
• GIF
Remember that these images are stored in the iProtect database. For performance reasons it is advised
to limit the size of the images to max 2 Mb.

2.2 Department

On the form with person details there is a drop down box where you can select the department this
person belangs to. The drop down box is filled with departemtns that have previously been created in
the system.

2.2.1 Creating departments

Departments can be created or changed via: Menu | General | Settings | Department.
Currently, the maximum number of departments in iProtect is 4096.

2.2.2 Name

Logical name of the department
Type: text
• Default: empty
• The name is mandatory
• Max value: 40 characters (60 from 10.4.X onwards)

2.2.3 Authorization Group

Selection of the authorization group for this department.
An authorization group determines which records/ objects may be used/ configurated/ shown by a
system user.
Type: drop down list
• List of all the programmed authorisation groups

2.2.4 Code

Unique reference code for a department and mostly used for third party connections or as reference
number for documentation.
Type: number
• Default: empty
• Min value: -2147483648
• Max value: 2147483647

2.3 Last event

This read-only field shows the time and date of the most recent event that has been logged for this
person. This can be any type of event (not only access event!).

2.4 Authorization group

Selection of the authorization group for this person.

An authorization group determines which records/ objects may be used/ configurated/ shown by a
system user.
Type: drop down list
• List of all the programmed authorization groups

2.5 User defined

For information that does not fit into any predefined data field a number of customizable data fields are
available. With these fields other, customer specific data can be used in the iProtect system.
For every person the following user defined data fields are available:

More information about these user defined fields and how to create them, you can find in chapter 6 on
Custom Fields. If no user defined fields are associated to the person form this section in the form will be absent.

2.6 Maximum of cards

Parking Area

If the Residents Parking license is present (license number 1502) a section is visible named Maximum
of Cards.

The field: “Parking area”, indicates with how many different access keys a person can enter the parking area.
By setting this field to (for example) 3, a person can have registered 3 different access keys with 3 different license plates for that parking area at the same time, even when APB e.g.: “Anti Pass Back” is active on all license plates and access keys. For any parking area the maximum value for this parameter is 4.

Access Area

The field “Access area”, indicates wheter a person can enter an access area multiple times with different
access cards, even when APB is active. The value of this parameter can be set on:

• Limited:

  • PAPB e.g: “Personal Anti Pass Back” is automatically applicable

  • A person is therefor only allowed to the area with one access card.

  • When presenting another access card the access will be denied.

• Unlimited:

  • A person is able to access the area multiple times with different access cards.

  • When APB is set active on the reader and the access key, a person is not able to access the area multiple times with the same access key anymore.

When the access is denied because the maximum number of cards has been exceeded for the parking area, when the access area parameter is set to Limited or when APB was set active with access area parameter set to Unlimited, the event “No Access” is logged with the error message that “too many cards for this person in the area (PAPB).

2.7 Person Class

If the Person Class enabled license is present (license number 1601) a section is visible named Person
Class.

A Person class is a freely definable selection field, Where special behavior for certain persons can
be triggered. For example with revolving doors that also have additional checks to determine wheter
multiple persons are trying to enter a single compartment, this check can be disabled for certain person
classes, i.e.: VIP’s.

The person classes can de created ( In English, Dutch and/or German) via the menu: General | Settings | Person Class. After creation the person class can be assigned to the specific person within the person form.

2.8 Area

In the section Area there is a field Maximum present time. This this field is part of the function is used
to detect if someone is present without leaving.
When a person is present for too long, a specific event will trigger a procedure for further action on this event.

The presence is calculated for all of the access areas together, however when in a specific area the precense is to be monitored it is to be defined within that specic area.

Maximum time present (hh:mm):
• No time set (blank): function is inactive
• Minimum amount of time: 01:00
• Maximum amount of time: 48:00

Specific transactions:
• Person present for too long=>

Use:
Generally, this function is used for large production plants to protect people from working for too long,
or for areas where people work alone and to monitor the safe presence of that person.

2.9 Linked persons

iProtect has the ability of obtaining personal information from other databases, like: Active Directory,
LDAP, Rijkspas, Alphapass or even another iProtect system (see chapter 5). This data is generally
obtained through a database synchronization proces. If this is the case, then it is a bad idea to allow the
iProtect user to change the person data fields that are synchronized with the other database, because
inconsistencies might be introduced in this way.
iProtect prevents the user from modifying synchronized data and informs the user by displaying is little
chain link icon in a green box, next to the Save button. This icon indicates a linked person.

Sometimes the synchronization is broken. For example in the case that a System User on the sending
server removes a person that was synchronized. In that case the link icon on the receiving server
changes into a red box with a broken chain icon. This indicated a broken link.

If the System user of the receiving server want to modify the person data in this case, first the link with
the data source must be removed. This can be done by clicking on the link icon and selecting the unlink option. The icon with the link is removed. Now the synchronization for these data elements are stopped
and the user can change the data fields. The other option is to delete the person directly.

To be able to unlink synchronized items the user must have special permission for this. This permission
can be granted via: Installation | Authorization | System user

By checking the box Synchronization manager the user gets these rights.

2.10 Additional Objects

In iProtect™ a number of other objects can be associated with a person. To add an additional object to a
person you can right click on the person in the tree-view to get the context menuA with the different
options. In below sub chapters these additional objects will be described in the more detail.

The following objects can be associated with a person:

• Card: for adding an access card to the person (See iProtect Cards manual)
• Employee: for adding employee data to a person (See chapter: 0)
• Vehicle: for adding information about a vehicle to a person (See paragraph 2.10.1)
• Contact: for adding contact information of a person (See paragraph 2.10.2)
• Memo: for adding memo information to a person (See paragraph 2.10.3)

And optionally

• Imported images: for adding images to a person (See paragraph 2.10.4)
• Restricted Area list: for adding restricted areas to a person (See iProtect Restricted Areas
manual)
• Guard tour list: for a guard tour to a person (See iProtect Guard Tour manual)

2.10.X Access Key (Card/ Tag)

Within iProtect™ it can be defined whom gets access, to which area’s and at what times. In order to get access, a person will be provided with an access key (Card or Tag). A Card/ Tag contains a unique number and other person data as explained in chapter 1.1 Information structure. Due to this Card or Tag the system can identify a person.

2.10.1 Vehicle

For information purposes, the information about the vehicle(s) of a person can be added to the database.
The following information can be added to the database:

• License plate number: String of max 20 characters with the license plate number.
Note: if the license plate number will be used for access control it has to be defined as a
Card. Here it is only for informational purposes!!
• Brand: The brand of the car (max 30 characters)
• Model: the model of the car (max 30 characters)
• Year: the tyear the car was built (Integer number)
• Colour: the colour of the car (max 30 characters)

2.10.2 Contact

A persons contact information can be added to the database. This can be both phone numbers and/or
e-mail addresses. A person can have an unlimited number of contact details.
These contact details can be used to (automatically) send information to a person. It can be used to
send reports, or inform a persons about an event via e-mail.

The following contact information can be defined:

• Means of communication: here 2 options are available:
o Phone number
o E-mail address
• Default: Here you can indicate the this is the default contact record for this person
• Description: You can give a short description for this contact information (i.e. work e-mail
address). This field is mandatory
• Phone number / E-mail address: Here the actual contact information is entered. This field is also
mandatory.
• Authorization group: the optional authorization group for this contact record.

Contacts can also be grouped into Cantact groups ( Menu | General | Contact | Contact group ). This
makes it possible to send out information to a whole group of persons.

2.10.3 Memo

For informational purposes a memo can be added to a person. A memo consist of 9 lines of free text
(maximum 32 characters).
A person can have at most 1 associated memo.

2.10.4 Imported images

If there are Imported images defined in the custom field definition (See paragraph 6.3), and added to
the Images Dialogue definition, these images are added to the person and available through the context
menu in the Person tree view.

By clicking on the image place holder, an image can be downloaded and added to the person. See
paragraph 2.1.2 for more information on this.

2.11 Reports

A customizable report is available to generate an overview of the persons in the database. This report
is available via:

Menu | General | Overviews | Reports | Person

A report can be generated by making a selection of the persons that must be present in the report.
The persons can be grouped on name ( 1 person per report page) or per department. With the option
show grouping, the name of the group (person name or department) is shown on the report page.

By default the person name and photo (if available) are shown on the report. Additional data elements
can be added to the report via the Report definition settings.

The report can be defined via:

Menu | Installation | Settings | Custom definition | Report definition

When selecting this menu item a list of configurable reports is shown. Select the person overview from
this list.

For this report you have to add an underlying element by pressing the right mouse button on the form
in the left tree view. For these forms there is only 1 selection possible: user defined.

Once the user defined underlying element is added, further elements can be added using the right
mouse button again. For each data element that must be added to the Person report form a new element
must be created.

For each element the following parameters are used:

• Table: The table that contains the data lement that is going to be used. The choices are limited
to the relevant tables for persons
• Column: The data element that will be used from this table.

The report that is defined through the Report definition menu is applied by default to all the users in
the system. It is however, possible to define different report for a mmber of a specific User group. If
such a report definition exists, this overrules the default report definition for these users.

The User Group specific report definitions can be created via the menu:

Menu | Installation | Authorization | User Group |

And then select the specific user group and open the Report definition. The definition of these reports
is similar to that of the system wide forms.

3 Employee data

This chapter describes the information that can be defined for employees in the iProtect system.

Currently, the maximum number of employee records in the iProtect database is 1.000.000.

3.1 Employee details

Menu | General | Employee

3.1.1 General information

In these fields the general information about the person can be entered.

• Person: Here the person can be selected to whom this employee data is linked.
• Administration number: The administration number of this employee. This field must be unique and is mandatory for all employees. It can be any character string (does not need to be a number) and may be maximum 60 characters long.
• Date of birth: In date format
• Minimum number of hours:
• Maximum number of hours:
• Nationality: Select the nationality of the employee from the list of coutries (ISO-3166)

3.1.2 Language

Here you can select the language for this employee. This selection is only relevant when using the
MyiProtect feature (See 3.3). The employee can use the MyiProtect interface in the language of choice.

3.1.3 Authorization Group

Selection of the authorization group for this employee.
An authorization group determines which records/objects may be used/configurated/shown by a
system user.

Type: drop down list
• List of all the programmed authorization groups

3.2 User defined

For information that does not fit into any predefined data field a number of customizable data fields are
available. With these fields other, customer specific data can be used in the iProtect system.

For every employee the following user defined data fields are available:
• 8 free selection boxes
• 2 free date fields

More information about these user defined fields and how to create them, you can find in chapter 6 on
Custom Fields.

If no user defined fields are associated to the employee form this section in the form will be absent.

3.3 Role

When using MyiProtect you can define here that this employee is a MyiProtect user.

When selecting this, you can define a username, user group and password for the MyiProtect account
of this employee.

4 Visitor data

iProtect contains functionality to handle the visitors. Visitors can be (pre-)registered, badges with specific
access rights can be assigned to them. The status and presence of the visitors can be tracked. Visitors
can be assigned to a host, who, for example, has to accompany the visitor through the building.

The visitor functionality in iProtect is available when license number 5040 Visitors enabled is present.

Visitors can be added to the system via the menu:

Menu | Visitor | Visitor

4.1 Visitor life cycle

In iProtect the visitor has a “life cycle”. Over time the status of a visitor will change and with this also the
data and actions that are associated with a visitor will change. In the figure below the life cycle of a
visitor in the system is depicted.
The color of the visitor icon in the tree view is related to the state of the visitor.

Figure 2 Visitor life cycle

When a new visit is added to the system, the visitor will be created in the state Announced or Present,
depending on the start date of the visit. If the visit is in the future the state will be Announced. If the start
date of the visit is now the state of the visitor will be Present.

When a visitor with the state Announced arrives at the company the user(receptionist) can inform the
host that the visitor has arrived by pressing the Announce button in the user interface. The state of the
visitor then changes to Arrived.

This state can be skipped by pressing the button Sign in. Then the state of the visitr goes to Present,
indicating that the visitor is now in the building. Also if the visitor has the state Arrived, the Sign in button
can be pressed to give the visitor the Present state.

In all states (Announces, Arrived and Present) the button Deregister is available to remove the visitor
from the system.

4.2 Displaying the list of visitors

When the standard visitor menu is selected, by default, the visitors that are present or expected for that
day are displayed when the Search button is pressed.
Also different selections for visitors are possible:

• Date of visit: by default the current date is selected. An additional selection field is present to
select visitors on the state of the visit (Announced, Arrived, Present). By default all visitors are
shown
• Card number: Visitors also can be selected on card number, A range of card numbers can be
entered and the selection can also be filtered on visitor state.
• Custom field: If custom fields have been defined with the Person data, these can also be used
as selection item.
• Name (visited person): The name of the person that is being visited
• Name (visitor): The name of the visitor.

4.3 Adding a visitor

After adding a new visitor via:

Menu | Visitor | Visitor

The possible data fields are displayed for a new visitor. Which fields are displayed and their default
value can be determined by System settings for a specific System User. So different System users
can have different default settings for new visitors.

At the top of the form the actual State of this visitor is shown. This is a read-only field. For an explanation
on the visitor states see paragraph 4.1.

4.3.1 Visitor details

The following fields are available:

• Start date/time: For the start date/time 2 options are available:
o Now: This means that the visit starts now. For example the visitor is at the reception
desk and is registered at that moment. In this case the visitor state is immediately set
to Present.

o Free date definition: Here you can enter a date/time in the future, for example when a
visitor is pre-registered by e-mail or the iVisit portal. The visitor then gets the state
Announced.
• End date/time: Here the end date / time of the visit can be entered. By default the beginning of
the next day is taken as the end day of the visit.
• Name/Prefix/First name: Here the name of the visitor must be entered. If the visitor is already
known in the system (because of earlier visits) the name can be selected via the combobox. In
Installation | Setting | Sysytem parameters | Database there is a setting that determines for
how many days the Visitor data is maintained in the database.
• Authorization group: Selection of the authorization group for this employee. An authorization
group determines which records/objects may be used/configurated/shown by a system user.

4.3.2 Vehicle

In the section Vehicle, the user can select from a drop down box whether or not the visitor comes/ came
with a vehicle. If New vehicle is selected, the license plate of the vehicle can be enterered.

The default value of this field can be set for a system user via System settingsfor this user:
Installation | Authorization | System user | user | Visitors | Default car option

4.3.3 Visitor Card

There are a number of fields that determine the properties of the access card that the visitor receives.
In this section these properties are discussed.

• Card: the user can select from a drop down box whether or not the visitor gets and access card
or not. If new card is selected a number of additional fields are shown. The default value of this
field can be set for a system user via System settingsfor this user:
Installation | Authorization | System user | user | Visitors | Default card option
• Layout: Here a KeyBadge layout can be selected when a personalized visitor card is printed
via the KeyBadge functionality. Only KeyBadge layouts are shown that are marked as visitor
layouts.
• Card number presentation: Here the card number presentation of the visitor card can be
selected.
• Card number: Thisis the card number of the access card the visitor receives.
• Access area: the access area the card is initially registered in.
• Parking area: the parking are the card is initially registered in.
• Card use: Here the card use of for the visitor card can be selected.
• Card group: The visitor card can be assigned to a card group. Only the card groups that are
marked as visitor card groups are displayed here. It is also possible to assign no cardgroups to
the visitor card. In that case the visitor can travel on the access rights of the host. See paragraph
4.6

4.3.4 Visted person

In this section the details of the person that is visited can be entered. In the Name field a list of persons
is displayed that can act as a host for the visitor. A person must have an access card to be able to be a
host.

When a visited person (host) is selected, for convenience, the department and a list of known phone
numbers of this person are displayed.

4.3.5 Optional fields

In the visitor dialog a few fields might or might not be present depending on the license and custom field
definitions.

4.3.5.1 Person Class

If the Person Class enabled license is present (license number 1601) a section is visible named Person
Class.

A Person class is a freely definable selection field, with which special behavior for certain
persons/visitors can be triggered. For example with revolving doors that also have additional checks to
determine wheter multiple persons are trying to enter a single compartment, this check can be disabled
for certain person classes, i.e. VIP’s.

The person classes that can be selected in this box can de defined via the menu:
Menu | General | Settings | Person Class

Here, new person classes can be added in 3 languages.

4.3.5.2 User defined

For information that does not fit into any predefined data field a number of customizable data fields are
available. With these fields other, customer specific data can be used in the iProtect system.

The user defined fields for visitor are the same as for persons. Therefore, please look at paragraph 2.5
for more details on this subject.

If no user defined fields are associated to the person form this section in the form will be absent.

4.4 Deregister a visitor

When a visitor leaves, the visit can be removed from the system by pressing the Deregister button. The
personal information of the visitor is kept in the system but the visitor will not be displayed in the list of
visitors for today, anymore.
Also the access card and its access rights will be removed from the system.

It is also possible to automatically deregister a visitor when (s)he leaves the building. To achieve this
the readers at the exit of the building can be set in the mode to log out visitors. In the Reader details
form on the Other tab page there is the option Log out visitors.
For this option there are 4 possible settings:

1. Don’t de-register visitor

2. Always de-register visitor. When a visitor offers the access card to this reader the visitor will be
   de-registered. Regardless of the validity of the access card or the duration of the visit.

3. De-register visitor at last day. The visitor is only de-registered at this card reader on the last day
   of the visit / validity of the access card.

4. De-register visitor at last two days. The visitor is de-registered at this card reader on the last
   two days of the visit / validity of the access card. This option can be necessary in situations
   where visitors are present 24 hours a day and you want to de-register a visitor whether (s)he
   leaves at 23:55 or at 00:05.

4.5 New Copy

When a group of visitors needs to be registered a number of data fields of the visitors are the same (like
the visited person). To speed up the registreation of multiple visitors the button New copy has been
added to the Visitor form. By pressing this button a new visitor can be created with a number of fields
that are copied from the current visitor.

4.6 Accompanied visitors

For visitors, iProtect has the capability of enforcing that visitors can only travel through the building when
they are accompanied by their host. This functionality is enabled by the license Restricted Areas
(licenseid=46) and when this license is present the settings for this functionality appear is the Reader
form. This functionality is further described in the manual iProtect Restricted Areas.

4.6.1 Inform host when visitor is on premises

An action is available named: Send mail to host.
This action sends a mail to the host of a visitor based on a procedure and action.

Example 1: Procedure and action settings when the visitors are signed in by the reception desk.

Procedure settings:
Subsystem: All subsystems
Event: Visitor state changed
Tab data: data 1: State visitor
Tab data: Value 1: selection box

• accepted

• announced

• arrived

• Present (recommended)

Action settings:
Send mail to host

• Operation: Automatic

• Change visitor state to: empty

• XSLT Stylesheet: yes

• Media element (XSLT stylesheet): empty (to use the default XSLT stylesheet)

Example 2: Procedure and action settings when the mail is sent when a visitor badges his visitor card
when he arrives.

Procedure settings:
Subsystem: Access control
Event: Access for subscriber card or Subscriber card: change access area (depending on
implementation)
Table 1: VISITOR
Data 1: visitor
Value 1: empty

Action settings:
Send mail to host

• Operation: Automatic

• Change visitor state to: arrived or present (depending on implementation)

• XSLT Stylesheet: yes

• Media element (XSLT stylesheet): empty (to use the default XSLT stylesheet)

Example 3: Procedure and action settings when the mail is sent when an announced visitor badges
his visitor card when he arrives.

Procedure settings:
Subsystem: Access control
Event: Access for subscriber card or Subscriber card: change access area (depending on
implementation)
Tab data: data 1: State visitor
Tab data: Value 1: selection box

• announced

Action settings:
Send mail to host

• Operation: Automatic

• Change visitor state to: arrived or present (depending on implementation wishes)

• XSLT Stylesheet: yes

• Media element (XSLT stylesheet): empty (to use the default XSLT stylesheet)

Note:
Action setting “change visitor state to” will change the actual visitor setting to the chosen value.

Note:
No mail is sent to the host when the host has no mail address in the system an error message will be
generated.

Note:
The layout and information in the mail can be changed to a customized layout by using a so-called XSLT
stylesheet. This customized stylesheet can be uploaded as media element.

4.7 System settings

The behavior of the visitor functionality can be configured through the System settings. These system
settings can be defined per System user, and therefore the behavior of the functionlaity can be different
for each user.

The System settings for the standard visitor functionlaity can be found at:
Installation | Authorization | System user | System settings | Visitors

The System settings also has an entry called Visitor registration, but these settings are for a special
visitor registration page which will be obsolete in the future.

For visitors the following settings are available:

• Standard authorization group: The authorization group field that is filled in by default

• Show short lists: Only show non-visitors and card holders in the list of hosts

• Present: card is required: When the visitor is present, an access card must be associated with
  him/her.

• Editable custom fields: Option whether or not the custom field related to the visitors are
  editable in the visitor dialog

• Default card layout: The default Keybadge layout for visitor cards.

• Automatic update: Whether or not the visitor list is updated automatically

• Behavior card intake unit: Chose the behavior of the card intake unit for this visitor card. This
  behavior field is only visible if the setting show behavior card intake unit is selected.

• Default card number presentation: The standard card number presentation for visitor cards.
  • Visitor time interval: Time interval between updates of the visitor list

• Default search keyword: Standard selection for the visitor list

• Default card settings: Whether or not default settings are applied to the visitor card

• Only one licenseplate per person: A visitor can have at most one card of type license plate
  associated.

• Maximum number of cards in parking area: Maximum number of cards that a visitor can use
  to enter a parking area (simulanuously). This is also the maximum number of parking spaces a
  visitor can occupy.

• Maximum cards in access area: Whether or not a visitor can enter an area with different
  access cards (soo also paragraph 2.6).

• Show behavior card intake unit:Whether or not to show the field behavior of card intake unit.

• Default car option: The default setting for the car field

• Default card option: The default setting for the card field

• Person class: The default setting for the Person class field. Only relevant if the license is
  present.

4.8 Reports

iProtect contains a number of standard reports on the visitors.
The following reports are available:

• Present in area: This report allows you to select one or more areas and show the actual
  presence of the visitors in the selected areas

• Period report: This report shows for a selected period the presence of visitors. It is also possible
  to make a report of advenced reservations for a period in the future. In that case one should
  select the free selection for the date definition and leave the end date open.

• Not checked out visitors: This is a report of visitors that currently have the present state in the
  system.

• Visitor statistics: This report will show the amount of vistors over a selectable period. It can
  show the amount per visitor state and per department.

5 Other data sources

A common requirement for the person and employee data in the iProtect system is that it must be
possible to exchange this data with external systems. Person and employee information can be imported
from specific Identily management or Card management systems. Besides this there is a generic import
and export functionality of person and employee data that can be used for other, third party integrations.

5.1 External databases

iProtect has the possibility to connect to a number of different external databases.

5.1.1 Dutch government card

The Dutch government has a national solution for access control (Rijkspas). iProtect has an integration
with this solution. Card numbers and personal information from the Rijkspas CMS can be imported into
iProtect and usage information is returned to the Rijkspas central system. For this functionality licensenr
4700 is required. For more information on this integration, see the manual iProtect Rijkspas.

5.1.2 Active Directory and LDAP

A common database for personal and employee information is Microsoft Active Directory (AD), and more
general LDAP (of which AD is a Microsoft specific implementation). Certain relevant person data fields
can be synchronized with the LDAP directory. For this functionality licensenr 40 is required. This
integration only synchronizes the data fields, not the authorizations. So it does not provide single signon
on AD for example. For more information on this integration, see the manual iProtect LDAP.

5.1.3 Alfapass

In the habors of Anwerp and Zeebrugge a common card is used that allows workers and truckers to
enter the compounds of the different companies that are located in these harbors. iProtect has an
integration with the central card management system of this solution: Alfapass, so that these cards can
be used in the iProtect system, beside the “own” access cards of the company. For this functionality
licensenr 32 is required. For more information on this integration, see the manual iProtect Alfapass.

5.1.4 Server-server synchronization

In case a company has 2 or more iProtect systems, it can be desirable to have the same person and
employee data in both systems. For this, iProtect support the synchronization of person and employee
between iProtect instances. For this functionality licensenr 5030 is required. For more information on
this integration please see the manual iProtect Server-server integration.

5.2 Import/export

For general purposes the employee data and photo’s can be imported or exported from the iProtect
database.

5.2.1 Employee data

5.2.1.1 Export

The employee data can be exported via:
General | Import/export | Employee data | Export

The data can be exported from an XML or a CSV formatted file.

The export form has a view port with 2 tabs that show the results of the export. The Changed data tab
displays the data that has successfully been exported and the Errors tab should the errors that occurred
during the export.

5.2.1.1.1 XML

The format of the XML file is:

The tags in red are mandatory.

OPERATION
Indicates the type of change in the iProtect database.
OPERATION=1 this data was inserted in the iProtect database
OPERATION=2 the data was inserted or updated
OPERATION=3 the data was deleted from the database.

In the export you can chose between column name length short and long. With short names only the
column names are encoded in the XML tags and with long names, both table names and column names
are encoded in the XML tag. So the RCN number will be encoded as <RCN>1234</RCN> with short
names and <ACCESSKEY_RCN>1234</ACCESSKEY_RCN> with long names.

The export page also has an option to export all employee data or export only the data of employees
that have modified data since the previous export.

For user defined field it can be ambiguous wheter a number should be interpreted as a number (1234)
or as a text string (“1234”). With the field User defined field as this can be defined in the export file.

5.2.1.1.2 CSV

The format of the CSV file is a comma seperated file with on each row the data fields of an employee.
The data fields are identical to the above described XML format. On the first line of the CSV file are the
column headers. For the CSV file export the same options are applicable as for the XML file export.

5.2.1.2 Import

The employee data can be imported via:
General | Import/export | Employee data | Import

The data can be exported from an XML or a CSV formatted file.

The format that is used for importing CSV or XLM files is exactly the same as that is generated in the
export of employee data.

The import form has a view port with 2 tabs that show the results of the import. The Changed data tab
displays the data that has successfully been imported and the Errors tab should the errors that occurred
during the import.

5.2.2 Photos

For convenience, iProtect has the possibility to import and export photos/pictures of persons in bulk.

5.2.3 Export

Exporting pictures is done via the menu:
General | Import/export | Photo of person | Export

It is possible to make a selection of the persons of whom the picture is exported. All pictures are packed
into a zipped archive before exporting. The name of the pictures in the zip file can be based on the
administration number of the employee, the person name or a user defined field in the person data. It
this last case any data field in the person data.

5.2.4 Import

Importing pictures is done via the menu:
General | Import/export | Photo of person | Import

One can define the name of the zip file containing the pictures of the persons. Regarding the format and
size of the pictures, please refer to paragraph 2.1.2.

Also for the importing the name of the picture can be the administration number of the employee, the
name of the person or a user defined field in the person data.

With the option Overwrite existing picture one can chose whether a picture that is already in the
database for a certain person should be overwritten or not.

6 Custom fields

To provide customization and flexibility in the use of personal data in the iProtect system, the user can
add custom fields to the database.

iProtect supports custom fields in 3 areas:
• Custom fields related to persons
• Custom fields related to employees
• Custom images

These custom fields can be defined through the menu selection:
Menu | Installation | Settings | Custom definition | Field definition

Once these fields have been defined they can be added to the person or employee form via the dialog
definition.
Menu: Instalation | Settings | Custom defenition | Dialog defenition

These custom fields can also be used as search filters in the user interface and as additional information
fields in the events.

6.1 Custom person fields

Three different kinds of fields can be added to the data of a person:

• Free text: in total 14 free text field can be defined. In a free text field any text can be entered
  up to a maximum length of 41 characters. The name of the free text field can be defined in the
  3 languages that are avilable and for each free text field you can indicate if it is compulsory or
  not.

• Free selection: In total 14 free selection fields can be defined. A free selection field is a data
  field where a selection can be made out of a set of options. In the field definition form the options
  can be added via the right mouse button (add option). Each option has a sequence number and
  can have a label in 3 languages. Also the free selection field itself has a label and them option
  to make this free selection compulsory or not.

• Free date: Two free date fields can be defined for a person. The format of the date field can be
  selected. The options are:

Also the free date field itself has a label and them option to make this free date compulsory or
not.

6.2 Custom employee fields

For empolyees 8 free selection fields and 2 free date fields are available. For the explanation of these
fields, please see the previous paragraph on Custom person fields.

6.3 Custom images

Besides the standard photo that is acssociated to a person, 4 other images can be added to a person.
This could be used to add for example a scan of a persons passport or a scan of some kind of
accreditation that could be required by an operator or a security guard to determine if somebody is
allowed entrance.
For each custom image type, the name can be defined in 3 languages and whether it is compulsory to
add an image to a person or not.

The following image formats are supported:
• JPG
• PNG
• GIF
Remember that these images are stored in the iProtect database. For performance reasons it is advised
to limit the size of the images to max 2 Mb.

6.4 Dialogue definition

After the creation of the custom fields and images, they can be added to the forms so they are available
when filling in personal details of persons, empolyees and visitors.

The forms can be defined via:
Menu | Installation | Settings | Custom definition | Dialogue definition

When selecting this menu item a whole list of configurable forms is shown. In all these forms, custom
fields can be added to the forms. In this document we will discuss the Person, Employee, Visitor and
Images dialog configuration.

For all 4 forms you have to add an underlying element by pressing the right mouse button on the form
in the left tree view. For these forms there is only 1 selection possible: user defined. (for other forms
there can be other selections).

Once the user defined underlying element is added, further elements can be added using the right
mouse button again. For each item that must be added to the Person/Employee/Visitor form a new
element must be created.
To add custom images to a person you can add the the defined custom image types to the Images
dialog definition.

For each element the following parameters are used:

• Position: This determines the order in which the custom fields are presented in the form

• Functionality: This has no function for this type of form

• Table: The table that contains the custom field that is going to be used. Possible choices: for
  the Person form, only the PERSON table, for the Employee form, only the EMPLOYEE table
  and for the Visitor form, only the PERSON table.

• Column: The custom data field that will be used.

• Compulsory: Whether of not the field has to be used in the form (otherwise the record can not
  be saved)

• Show: Whether or not the field has to be shown on the form.

• Show in selection: For the Visitor form this checkbox determines if this custom value is shown
  together with the visitors name in the treeview and the visitor selection field on the form. For the
  person and employee form this field has no meaning.

• Default value: Whether or not each new person/employee/visitor gets a default value filled in
  for this custom field. If the checkbox is checked, a value field appears in which the default value
  can be entered.

The forms that are defined through the Dialogue definition menu are applied by default to all the users
in the system. It is however, possible to define different dialog forms for a mmber of a specific User
group. If such a dialog definition exists, this overrules the default dialog definition for these users.

The User Group specific dialog definitions can be created via the menu:

Installation | Authorization | User Group |

And then select the specific user group and open the Dialogue definition. The definition of these forms
is similar to that of the system wide forms.