Synergi Administration Manual

A M
SYNERGI™ LIFE
Version 16.13.0
SAFER, SMARTER, GREENER

Reference to part of this report which may lead to misinterpretation is not permissible.
Prepared by DNV GL – Digital Solutions
© DNV GL AS. All rights reserved
This publication or parts thereof may not be reproduced or transmitted in any form or by any means, including
copying or recording, without the prior written consent of DNV GL AS
Contents
1 Introduction to the administration application 5

1.1 Code administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Language configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Interface administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Workflow configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5 Special reports, dashboards and favourites configuration . . . . . . . . . . . . . . . . . . . 11
1.6 Reports from the administration application . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7 Message to users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.8 System table configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.9 Administration tools on the web application . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Information for new administrators 14

2.1 Find the correct text or code to update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Find a code in a codetable and add a new code . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Code administration 17
3.1 What are codetables? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Code administration hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Explanation of ‘Properties’ for codetables . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4 Codetables with ‘list’, ‘type’ and ‘connect type/list’ . . . . . . . . . . . . . . . . . . . . . . 23
3.4.1 Location ‘type’, ‘list’ and ‘connect type/list’ . . . . . . . . . . . . . . . . . . . . . . . 23
3.4.2 Unit ‘type’, ‘list’ and ‘connect type/list’ . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 References and Reference Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5.1 Properties for References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 User Group Administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.6.1 How to administrate hierarchical user groups . . . . . . . . . . . . . . . . . . . . . . 28
3.6.1.1 User group in the User group properties dialog box . . . . . . . . . . . . . . . 31
3.6.2 Link codes to user group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7 Reorganize codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7.1 Move codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7.2 Merge codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.8 Status type - Open/Closed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.9 How to set up Check lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.9.1 Check lists – Score calculation weight . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.10FAQs Code administration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.10.1How to reorganize a code that is going to be transferred into two new codes . . . . . . 49
3.10.2How to make sure that employees in a specific geographical area only have access to the
code structures they need . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.10.3How to ensure that the same company does not exist many times under different names 50
4 Language configuration 51
4.1 Update an existing text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1 How to find which text number to update? . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Add a new text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Add a new code in a codetable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
CONTENTS Page 1
4.4 Update the description of a code in a codetable . . . . . . . . . . . . . . . . . . . . . . . . 53
4.4.1 Change the name of a case type or the explanation of the case type . . . . . . . . . . 55
4.5 Update the name of a folder, screen or background text used in the administration application 56
4.5.1 How to update the names of the screens in the administration application . . . . . . . 57
4.5.2 How to update the names of the ‘folders’ in the administration application . . . . . . . 58
4.6 How to export Texts and Code Descriptions to Excel . . . . . . . . . . . . . . . . . . . . . . 59
4.6.1 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6.2 Code descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 User administration 64
5.1 User – Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.1.1 Change User ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.1.2 Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1.2.1 Password policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.1.2.2 How to force the users to change password regularly . . . . . . . . . . . . . . 69
5.1.3 User Details - Unit and Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2 Authorisation - operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.2.1 Approve access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2.2 Access to the application “Synergi Life” vs “Synergi Life Tools” . . . . . . . . . . . . . 72
5.3 Default values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4 Access to screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.5 Extended access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.6 Visible for fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.7 Restricted access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.8 Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.9 Access to administrate user group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.10Alternative ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.11Additional Information - Extra information for code tables . . . . . . . . . . . . . . . . . . . 78
5.12Access to cases and actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.12.1Access to read a case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.12.2Access to edit a case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.12.3Access to edit an action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.13Give access to users vs access to roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.13.1How to assign a role to a user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.13.2What does it mean to assign a role to a user? . . . . . . . . . . . . . . . . . . . . . 80
5.14Duplicate user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.15Delete user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.16Search for users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.17Search for roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.18User with administrator access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.18.1Restrictions for Local / Limited local administrators when doing User Administration . . 89
5.18.2Access to assign roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5.19How to set up default values for the users . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.20Export the list of users to Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
6 Dashboard Configuration 99
6.1 Processing dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2 Default dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.3 Give access to creating dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.4 Step by step example of creating a new dashboard . . . . . . . . . . . . . . . . . . . . . . 103
6.4.1 Create a dashboard type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.4.2 Create folder for all the dashboard favourites . . . . . . . . . . . . . . . . . . . . . . 104
6.4.3 Create 2 favourites to be used on the dashboard . . . . . . . . . . . . . . . . . . . . 106
6.4.4 Connect Favourites and Dashboard type . . . . . . . . . . . . . . . . . . . . . . . . 107
6.5 Summary of how to create a new dashboard . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.6 Doing changes to existing dashboard types . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.6.1 Change in Dashboard type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
CONTENTS Page 2
6.6.2 Change in Favourites used in dashboard type . . . . . . . . . . . . . . . . . . . . . . 110
6.6.3 Change search parameters or layout for existing favourites . . . . . . . . . . . . . . . 111
6.6.4 Change the dashboard on the start-up page . . . . . . . . . . . . . . . . . . . . . . 111
6.6.5 Explanation of difference between Alternative 1 and Alternative 2 favourites used for
‘Processing dashboard’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.7 What to check if the user cannot see the dashboard? . . . . . . . . . . . . . . . . . . . . . 112
6.8 What is limiting the content of the dashboard? . . . . . . . . . . . . . . . . . . . . . . . . 112
6.9 Drilldown from favourites in dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.10Link to dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7 Reports in the administration application 115

7.1 How to check for duplicate registrations of cases (Quality Control Report) . . . . . . . . . . . 115
7.2 Code table report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
7.3 Experience Transfer Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
8 Refresh cache 118

8.1 When to refresh the cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.2 How to refresh the cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
8.2.1 Refresh cache for the web application . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9 Workflow configuration - Configuration for administrators 120

9.1 How to set up a field as a mandatory field . . . . . . . . . . . . . . . . . . . . . . . . . . 123
9.1.1 Remember the old cases when setting up a field as a mandatory field . . . . . . . . . 123
9.1.2 Where to set up field as a mandatory field – Case registration constraints . . . . . . . 124
9.1.3 Example of setting the “How revealed” field as a mandatory field . . . . . . . . . . . . 125
9.1.4 How to set up mandatory fields in the registration screen or when importing cases from
other databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
9.2 Default value configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
9.3 Extra information for code tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.4 How to set up transfer of experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
9.4.1 Short list of the steps to go through to set up experience transfer . . . . . . . . . . . 129
9.4.2 How to activate a criterion for transfer of experience . . . . . . . . . . . . . . . . . . 130
9.4.2.1 Link Criteria and Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
9.4.2.2 Link Criteria to Operation and Input Form . . . . . . . . . . . . . . . . . . . 130
9.4.2.3 Link Criteria Type to Operation and Input Form . . . . . . . . . . . . . . . . . 131
9.4.3 Subscriber group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
9.4.4 Subscriber group members . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
9.4.5 Link Experience transfer criteria – Subscriber group . . . . . . . . . . . . . . . . . . 132
9.4.6 Case Processing Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
9.4.7 Anonymous transfer of experience . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
9.5 DB initialization Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
9.5.1 Contact information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
9.5.2 How to change sender of Synergi Life e-mail . . . . . . . . . . . . . . . . . . . . . . 134
9.5.2.1 Sender of notification e-mails . . . . . . . . . . . . . . . . . . . . . . . . . 135
9.5.2.2 Sender of transfer of experience e-mails . . . . . . . . . . . . . . . . . . . . 135
9.5.3 Logging when users are reading case information . . . . . . . . . . . . . . . . . . . . 136
9.5.4 Help menu with link to External URL . . . . . . . . . . . . . . . . . . . . . . . . . . 137
9.5.5 How to make Name and E-mail address readonly in User Profile . . . . . . . . . . . . 137
9.6 Administration Type Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
9.7 Case processing configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
9.7.1 How to ensure that the initial reporter receives an e-mail when the case is being approved
and closed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
9.8 Administration of search indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
9.8.1 Index Search . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
9.8.1.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
9.8.1.2 DB_INI-settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
9.8.1.3 Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
CONTENTS Page 3
9.9 Case registration domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
9.10Connected cases configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.10.1Visible case types for new case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.10.2Information to copy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.10.3Connection type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
9.10.4Default filter connect case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
9.10.4.1Default filters connect case - subordinate . . . . . . . . . . . . . . . . . . . . 146
9.10.4.2Default filter connect case - duplicate . . . . . . . . . . . . . . . . . . . . . 147
9.10.4.3Default filter connect case - barrier connection types . . . . . . . . . . . . . . 149
9.10.4.4Default filter connect case - connect current case to any case in bowtie . . . . 150
10Special reports, dashboards and favourites configuration 151

10.1Case and action reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
10.2Default fields for reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
10.2.1Default distribution options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
10.2.2Default filter domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
10.2.3Default selection group by domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
10.2.4Default selection quantify domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.2.5Default target applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
11FAQ – Frequently asked questions / Other functionality 159

11.1How to configure and in which order? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
11.2Can the date/time set-up be changed to 24/12, am/pm, mmddyy or ddmmyy? . . . . . . . . 159
11.3How to remove a value in a hierarchical field (Eraser button) . . . . . . . . . . . . . . . . . 159
11.4How to add messages to the users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
11.5Environmental management module administration . . . . . . . . . . . . . . . . . . . . . . 162
11.6Menu option Grant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
11.7Risk Matrix Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
11.8How to copy Responsible unit to Unit in charge for new cases . . . . . . . . . . . . . . . . . 163
11.9Missing users in “Person in charge” dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
11.10
Administration of scheduled reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
11.11
How to unlock locked cases (SynergiLockedCases.exe) . . . . . . . . . . . . . . . . . . . . 164
CONTENTS Page 4
Chapter 1
Introduction to the administration

application
The administration of Synergi™ Life is constructed in a logical and structured way with the intention to
enable the administrator to navigate easily through the system. The administrators in Synergi Life can only
read/edit the administration screens that they are given access to. Some of the administration is done in
the administration application Synergi.exe, and some of the administration is done in the web application.
The majority of the administration can be managed by your own company after some training.
Synergi Life Administration Application Synergi.exe
The administration application is constructed as a logical hierarchy.
CHAPTER 1. INTRODUCTION TO THE ADMINISTRATION APPLICATION Page 5

1.1 Code administration
The Code administration section is one of the most important parts in the administration application. Code
administration represent all fields where the end user can select a predefined option from a list (e.g. Company,
Unit or Location). The contents of the codes are maintained by the administrator.
Example of Location Hierarchy code administration.

See separate chapter about the Code administration for more information.
1.2 Language configuration
All texts/sentences used in Synergi Life can be translated in the Language configuration section. The
texts in the Text screen is either a background text used in the web application or in the administration
application. The descriptions in the Translation of Code Descriptions screen is a translation for a code in
a codetable (for example “Norway” in Location).
See separate chapter about the Language configuration for more information.
1.3 Interface administration

Interfaces to other systems as well as import/export of cases from other Synergi Life databases can be
administrated in the Interface administration section.
1.4 Workflow configuration
In the Workflow configuration section, it is possible to define case processing configuration. Here the

administrator can set up which fields that are mandatory when saving, approving or closing a case. It is also
possible to set up default values and automatic transfer of experience.
See separate chapter about the Workflow configuration for more information.

1.5 Special reports, dashboards and favourites configuration
This section has options for configuring reports, special reports, dashboards and favourites.
See separate chapter about the Dashboards for more information.
See separate chapter about the Case and action reports for more information.
See separate chapter about the Default fields for reports for more information.
See the separate Special report document for more information.
1.6 Reports from the administration application
The administration application provides three reports:
• The Code table report screen contains an overview of the code numbers and descriptions.

• The Experience Transfer Report screen contains an overview of the cases where transfer of expe-
rience e-mails have been sent.
• The Quality Control Report screen contains an overview of all the cases that have been registered
at approximately the same location, unit and time.
See separate chapter about the Reports for more information.
1.7 Message to users
See separate chapter how to set up Message to users that will be displayed when the users log in to the
Synergi Life web application.
1.8 System table configuration
The System table configuration section is the “control and logic center” of Synergi Life. This part of the
application is protected by password and restricted to Synergi Life personnel only. Configuration of Synergi
Life is explained in the Configuration manual.

1.9 Administration tools on the web application
These administration tools are available from the web application:
• User administration + Role administration

– Administration of users and roles. See separate chapter.
• Refresh cache
– Updates the web application with the latest changes from the configuration in the administration
application. See separate chapter.
• My downloads
– Export cases and reports from Synergi Life
• Import
– Add cases from another system or another Synergi Life database
• Regenerate aggregated environmental data
– Make sure that the tables used for the Environmental Values are updated
• Regenerate aggregated risk data
– Make sure that the tables used for Risk are updated

Chapter 2
Information for new administrators
All words/sentences that are used in Synergi Life can be updated and translated. As an administrator, it is
necessary to know how to find the correct text/code to update. It is also important to know how to add a
new item and make it appear in a list in the case registration screen.
2.1 Find the correct text or code to update
Example screenshot of a case:
• The texts marked with ORANGE are background texts translated in the Text screen.
• The texts marked with GREEN are codes in a Codetable.
– The codes can be translated in the Translation of Code Descriptions screen.
– Most codes can also be translated in the Code administration section.
• The texts marked with BLUE are free-text fields where the end user can enter any characters. These
texts are not translated.
CHAPTER 2. INFORMATION FOR NEW ADMINISTRATORS Page 14

All translation can be done in the Language configuration section in either the Texts screen or the Trans-
lation of Code Descriptions screen. It is also possible to search for the word in both screens to determine
if it is a text or a code.
2.2 Find a code in a codetable and add a new code
If you want to add another item in a list, then the code must be added to the correct codetable. If you do
not know the name of the codetable that need a new item, search for another item that appear in the list in
the web application in the Translation of Code Descriptions screen to find the name of the Codetable;
then find the screen that have this ‘codetable name’.
Example: An end user asks you to add a new item in the “Supplier” field. The “Supplier” field is using the
“Company” codetable, but the field is not named “Supplier company”. How do you find the correct codetable?
Find other items in the field. In this example: Halliburton, Schlumberger or Seadrill.
• Search for one of the other items in the Translation of Code Descriptions screen.
• Enter the name of the item in Description, click Select or F5.
• Find the name of the Codetable. Here: Company
• Find the screen with the name of the codetable.

• Double check that the suggested new item does not already exist; the item may exist, but for some
reason the end user cannot find the item in the list. The item may be disabled or not visible for the
current user group.
• Add a new item. Here: Add a new company.

Chapter 3
Code administration
3.1 What are codetables?
Codetables are all fields in the web application where the end user can select a predefined code from a list
e.g. Company, Unit or Location. The opposite of codetables are fields where the end user can enter any
text, numbers or dates; these are not codetables. The contents of the codetables are maintained by the
administrator.
All codes in the codetables can be translated into all languages that are activated in the database.
The codetables can either be hierarchical (like Location) or a list (like Company).
The administration of the codetable are organized in folders matching the sections in the web application for
the extensive users.
There are several possibilities to limit the content of a codetable.
• Disable a code that should no longer be used.

• Set the code to only be visible for some user groups.
• Set the code to only be visible for some case types.
• Set the code to only be visible for some fields (this can be used if one codetable is used for several
fields like unit-codetable and fields ‘Unit in charge’ and ‘Responsible unit’).
How to limit the content of a codetable will vary from one codetable to another.
Hierarchical codes can be moved from one place to another. This can e.g. be used if the company reorganize
the units/departments.
Two codes can be merged; meaning that the two codes are put together into one code. This can e.g. be
used if the company wants to simplify the codes in the Case Category field and want to combine the codes
‘Helicopter accident’ and ‘Car accident’ into a more general category called ‘Transport accident’.
Example of a list codetable: Body part
CHAPTER 3. CODE ADMINISTRATION Page 17

Example of a hierarchical codetable: Work process
3.2 Code administration hierarchy
The Code administration follows the same logic as the extensive interface in the main application. This
makes it possible to follow the path where the field is located, and find the code administration for the field

that needs to be changed. Code administration section: Where and What is the first folder, User Group
Administration is the last folder, the other folders are alphabetically ordered.
3.3 Explanation of ‘Properties’ for codetables
The different codetable can have different properties.
All codetables can be translated.
Mark the code you want to translate and click Properties.
Example: “Head” is called “Hode” in Norwegian.

Some codetable have User group, Visible and Case types in Properties.
If a code is visible for a User group, then all users that have this user group as the Current user group
will see the code.
Example: A Unit may be visible only for some user groups.

If the same codetable is used for several fields, then it is possible to set a code Visible only for some of the
fields.
Example: If a work process is not relevant to be used as a Target-process, then this code may be set as not
visible for this field.

Some codetable can be set visible for some of the case types.
Example: ‘Survey receiver’ in the Person involved as codetable is probably only a relevant code for the
Third party management module.

3.4 Codetables with ‘list’, ‘type’ and ‘connect type/list’
The purpose of codetables with ‘type’ is to easily search or run analysis of what happened for units/locations
of a certain type.
Examples:
• How many people were injured ‘offshore’ last year?

– Instead of creating a search for all locations and remember to include all platforms etc - simply
search for ‘Location type’ = ‘Offshore’
• How many patients were treated at units having patients 24 hours each day? (opposite to units only
open during day time Monday-Friday)
– Search for ‘unit type’ = ‘Units open 24-7’
• What are the evaluation of all the check list items that are used to prevent accidents from occurring?
– Search for ‘check list type’ = ‘Preventive’
– E.g. Reflective clothing and lights can help preventing an accident from occurring. (opposite to
helmet and safety belt that may reduce the consequences if an accident occurs)
3.4.1 Location ‘type’, ‘list’ and ‘connect type/list’
Location types are specified in the Location – type screen, e.g.: Offshore, Inshore, Offshore Installation,
Marine Vessel, Helicopter and Cafeteria. Note that one specific location can be connected to several location
types. E.g. the location ‘Cafeteria Sea’ can be of both the type Cafeteria and Offshore.
Location - type
Locations are defined in the Location – list screen.
Now, locations can be connected to location types in the Location – connect type/list screen. In this
example, Cafeteria Sea is connected to the Location type Offshore and Cafeteria Land is connected to the
Location type Inshore. In addition, the two locations are also connected to the location type Cafeteria. I.e.
a location can be connected to more than one location type.

Location - Connect type/list, Offshore
Location - Connect type/list, Inshore
Location - Connect type/list, Cafeteria
This set-up is performed by the administrator to facilitate case searches. Location list and location type can
be used as a parameter when performing advanced searches. Choose the Location type Offshore to get a
list of Synergi Life cases that have been reported offshore. Choose the Location type Cafeteria to get a list
of Synergi cases that have been reported in a Cafeteria (Offshore and Onshore).
Another example: The end user might want to perform a search for all cases that are “offshore”. Instead of
selecting all offshore locations in the hierarchy, the end user can search for the location type “offshore”. To
make this work the Synergi Life administrator must define which locations in the location list that are located
offshore. The administrator only needs to do this definition once to make it faster and easier to perform
searches.
3.4.2 Unit ‘type’, ‘list’ and ‘connect type/list’
This is an example unit hierarchy from the health/hospital segment. Unit types are specified in the Unit –
type screen.
Unit - type

Units are specified in the Unit – list screen.
Now, units can be connected to unit types in the Unit – connect type/list screen.
Unit – connect type/list, Laboratory
Unit – connect type/list, Ward

Unit – connect type/list, Medicine
Unit – connect type/list, Surgery
Unit list and unit type can be specified as an advanced search parameter (Reported by unit / Reported by
unit list, Responsible unit / Responsible unit list). Choose the Responsible unit type Laboratory to get a list
of Synergi Life cases where the responsible unit is any laboratory. Choose the Responsible unit type Ward
to get a list of Synergi Life cases where the responsible unit is a ward. Choose Responsible unit list Lab – S2
to get Synergi Life cases where the responsible unit is this particular Laboratory. In this way, it is possible
to compare Synergi Life statistics; e.g. cases with different responsible units, but same unit type.

3.5 References and Reference Options
For each version of Synergi Life a certain number of standard fields can be used, e.g. Location, Responsible
unit, Work process, System involved.
If it is necessary to add further fields they can be added as References. A reference is an extra field which
can be administrated by the customer.
References added to the Reference screen in the administration application, will appear in the Reference
grid in the web application. It is also possible to create a reference as a separate field like e.g. Location, but
this is a configuration task which can be done by DNV GL / DNV GL partners.
There are several types of References
• Text
– A text reference is a field where any characters can be entered.
• Regular expression
– A regular expression reference is a type of text reference. The reference has “rules” for text
formatting.
• Single selection
– In a single select reference field it is possible to choose between predefined Reference options.
– The Reference options can be a list or a hierarchy.
• Multi selection
– In a multi select reference field it is possible to choose between predefined Reference options.
– The Reference options can be a list or a hierarchy.
• Date
– Only dates are allowed in date fields.
• Date and time
– Only date and time are allowed in date and time fields.
• Integer
– Only integer numbers are allowed in integer fields.
• Float
– Only float numbers, with or without decimals, are allowed in float fields.
• Checkbox
– A checkbox is checked or unchecked.
– The values for checked and unchecked in defined in Reference option and then added to the
Reference screen.
The Reference and Reference option screens in the administration application is located under the sections
General Classification, Actions and in all the Consequences.
3.5.1 Properties for References
As all other codes, References also have a properties dialog. Mark the reference and click Properties.
Language: Translate the reference and the long description of the reference. The long description is used
to guide the user to what kind of information to add.
User group: Indicates which user groups should see this reference when clicking “New” in the reference
table in the web application.
Visible: The reference can be visible/invisible for many different reference tables in the web application;
one for the case, one for actions and one for each consequence.
Case types: The reference can be used for as many case types as required. When creating a new reference,
it will automatically be connected to all case types (at top level “Synergi Life”). If the reference should only
be visible for certain case types, remember to delete Synergi Life from the list.

3.6 User Group Administration
A user group determines which codes that should be visible for a field.
All users have a ‘current user group’. The access to this group determines which codes the user see in the
different fields.
All users have a ‘main user group’. The access to this group determines which user groups the user can
choose between in ‘current user group’ field.
3.6.1 How to administrate hierarchical user groups
To administer user groups more efficiently it is recommended to organize user groups hierarchical. A code
visible for a specific user group is also visible for its child user groups.

When administrating user groups it is recommended to start with one user group at the top and give it access
to all codes that all user groups should have access to. Then create an empty child user group.
When creating a new User group it is possible to copy an existing user group or create a new empty group.
The child user group will automatically have access to all codes the parent user group can access. Add the
access the child user group should have in addition.
Example: The code administration for Product has 3 codes.

Product A should be visible for everyone. Since the parent user group Company X can see the code, all child
user groups also can see the code. It is not possible to remove the code for any of the child user groups
(without unchecking the code for Company X).
Product B should only be visible for the user group Administration and all child user groups (here: IT).
Waste should only be visible for cleaning personnel.

3.6.1.1 User group in the User group properties dialog box
Access related to a user’s main user group, determines which user groups the user should be able to choose
between in the Change user group dialog box.
Example: Change user group

The logged on user has CompanyX as current user group (shown in User Group field). The user can choose
between CompanyX …
… and the two child user groups Administration and Production.

The user’s Current user group is CompanyX. The user’s main user group is Production.
The user can only choose between these three user groups because the user’s main user group (Production)
only has access to the three user groups in the properties dialog box.

3.6.2 Link codes to user group
In the Link codes to user groups screen it is possible to administer all codes that should be visible for one
user group.
User group CompanyX has access to Case category Falling object, Helicopter incident and transport accident.
CompanyX does not have access to the remaining two case categories.
In the Case category screen it is possible to see (and update) which user groups that are allowed to see
the case category (2 - Food poisoning).

3.7 Reorganize codes
It is possible to rearrange codes in the code administration. Codes in a list can be merged together. Codes
in a hierarchy can be merged or moved.
NB! It is not possible to “undo” a merge operation. Once two codes have been joined it is not
possible to separate them again.
3.7.1 Move codes
When moving a code this code will be changed in all existing cases.
Example of MOVE codes:

Similar case categories: Boat accident, Car accident, Helicopter accident, Transport accident.
It would be more logical if all transport accidents were grouped beneath the case category “Transport acci-
dent”.
How to move the codes
• Right click at the item that should be moved and select Reorganise from.
• Right click at the item that should be the new parent item, select Reorganise to and select Move.
Result:
• A case with case category “Car accident” will be displayed as “Transport accident – Car accident”.
• A case that was registered with “Transport accident” has not been changed.

3.7.2 Merge codes
When merging a code this code is changed for all existing cases. The “merged” code will no longer exist.
Example of MERGE codes:

Company A buys Company B. The code Company B should no longer be used. There are two options:
• Option 1: Disable Company B. ‘Reported by company’ will still show as Company B, but it is no longer
possible to select this item in the company list.
• Option 2: Merge Company B into Company A. Cases containing Company B as ‘Reported by company’
will show Company A. Cases containing Company A as ‘Reported by company’ will still show Company
A. Company B will no longer exist in the code administration; neither in the web application nor in the
Code administration section.
How to merge two codes
• Right click at the item that should be merged and select Reorganise from.
• Right click at the item that should be the new parent item, select Reorganise to and select Merge.
3.8 Status type - Open/Closed
Each customer can themselves decide which statuses that are defined as “Open” and which statuses that
are defined as “Closed”.
The open/closed statuses are used in predefined searches like
• Action in process
• Cases in process
• Closed cases
Read more about the predefined searches in the User Manual, chapter about “Predefined filters”.
‘Case status types’ are defined in the Workflow configuration section:
• Status - type
• Status - Connect to type
‘Action status types’ are defined in the Code administration section:

• Actions
– Action status - type
– Action status - connect to type
Example: All case statuses are defined as “Open”, except for Rejected and Closed
Example: “Closed” statuses
NB! It is possible to add one status to several ‘Status types’. However, it will not make sense to have one
status as both ‘Open’ and ‘Closed’.

3.9 How to set up Check lists
Check lists can be used to register behaviour based safety which is a default check list in Synergi Life. More
check lists can be defined.
Check list – category: Determine which categories the company wants to use. The categories may for
instance be behaviour based safety for different tasks. Examples: offshore, climbing, diving, welding,
patient care, customer service etc. Remember to add the user groups and case types where the category
should be visible.
Check list – list: Add all the items that should be used in the Check list – hierarchy. All the items that
should be a part of any hierarchy must first be listed in the Check list – list. This will make it possible to
make an item available in several hierarchies. For instance, “Use of Personal Protective Equipment” will be
a part of both Diving and Climbing safety, but what kind of Personal Protective Equipment the person need
depends on the work task.

Check list – hierarchy: Select a category and create the hierarchy for this category. Remember to add
the user groups and case types where the item should be visible.
If the user should see a Check list item, the user’s current user group must have access to both the Check
list – category AND the item in the Check list – hierarchy. In addition the correct case type must be
added in both the Check list – category AND for the item in the Check list – hierarchy. If one item is
not visible for a user group in the Check list – category or in the Check list – hierarchy (or both), this
user group will not see the item.
If the user groups and case types are limited in the Check list – category it is possible to add all the user
groups and all the case types in the Check list – hierarchy. If the access needs to be changed later it is
only necessary to change the access in the Check list – category, instead of changing all the codes in the
Check list – hierarchy.

Remember to add a Sequence number for all items in the check list hierarchy. All Sequence numbers at level
1 should be unique. All Sequence numbers for all check list items that have the same parent item should
be unique. If the items in the check list hierarchy do not have a Sequence (that is unique) then the “next at
risk” button in the web application might not work properly.
Example: “Body position” and “Use of Personal Protective Equipment” should have different Sequence num-
bers. All child items below “Use of Personal Protective Equipment” should have different Sequence numbers.
The Check list – type is optional to use, it is not necessary to use it in order to make the Check lists work.
This works in the same way as Location type and Unit type.
Example of use of the Check list – type; Safety equipment may be separated into two types:
• Equipment to prevent the event from occurring: reflective clothing, lights, automatically shutdown of
machine if it has not been used for the last X minutes/hours.
• Equipment to reduce the consequences if the event occurs: helmet, gloves, fire extinguisher
Check list – connect type/list screen, connect the type with the items in the list

Evaluation
The alternative for Evaluation type is by default Show details:

Show details are connected to the evaluation type At risk, Degraded/Uncertain and Not acceptable.
Evaluation - Connect to type
This means that for example At risk all the details are visible; Number of repetitions, What, Why,
Solution and Interaction. For Safe and Not evaluated the Check list details does not display any
details.
For Not acceptable and Degraded/Uncertain all the details are visible; Comments, Evaluation date,
What, Why, Solution.

Create Interactions and add Interaction options. Remember to add the user groups and the case types
where the codes should be visible.
Interactions:

Interaction options:
For each Behaviour based safety case that is registered, Observer is a mandatory field. The person that is
an observer is supposed to be anonymous; therefore, the case processing log is not visible for this case type.
However, it is possible to retrieve information about which user that has saved a case by performing a search
in Advanced search or running a Selection report. If it is irrelevant that the observer can be connected to
the user, the person can log in with the regular user id and have personal default value for the Observer
field.
For situations where the Observer is supposed to be 100% anonymous, one of the following two methods
can be applied:
• Option 1: Create one “ObserverUser” and only give the user access to save Behaviour based safety
case types. All persons that are observers must know the login name and password for this user.
When they log in, they find the correct observer in the list of observers. NB! All persons that log in as
the ObserverUser may change the password, personal default values and current user group to the
ObserverUser.
• Option 2: Create one ObserverUser for each Observer. To save time giving the Observer users access;
create one ObserverRole and give this role access to save Behaviour based safety cases. Connect the
ObserverRole to all the Observer users. Do not give the Observer users any access (this is already
given to the Observer role). Then encourage/help the Observers to add personal default values (also
for the Observer field) so that the registering of Behaviour based safety case is executed quickly.
Observer

3.9.1 Check lists – Score calculation weight
The score of a check list is calculated by =
“Score calc weight” for each check list item * “Score calc weight” for each evaluation
Each Evaluation has a “Score calc weight”
Each check list item has a “Score calc weight” (here: written in red in front of all items)

Check list item “Inspection result” will get a score of 2x2 = 4.
Check list item “Override log” will get a score of 1x3 = 3.
The other 6 check list items in the case have “Not evaluation” and will get 0 score.
The score of this case is calculated:
Score = 1x3 + 2x2 + 1x0 x 6 = 7
This give a Integrity status with score 7 “Degraded/Uncertain” (range 4-8)
Color = yellow.
Integrity status with score-range

3.10 FAQs Code administration
3.10.1 How to reorganize a code that is going to be transferred into two new
codes
It is not possible to “split” a code and then insert it into two new codes with the reorganize function in
Synergi Life. Nevertheless, it is possible to create scripts to “split” the cases connected to a code, if there
are any other criteria that can help define where the cases can be moved to. This should be done by qualified
Synergi Life personnel - through an agreement with DNV GL Software.
3.10.2 How to make sure that employees in a specific geographical area only
have access to the code structures they need
This requires that all user groups connected to those geographical areas are set up. This is done in the User
group section.
When the user group has been set up, open the Link codes to user groups screen. Define which codes
(here: work processes) should be visible for the different user groups. It is not possible to add or remove
items from this list, only to check/uncheck the check boxes.

3.10.3 How to ensure that the same company does not exist many times under
different names
The unique field for organization number ensures that the same company does not exist many times under
different names. It is displayed in the Company screen. The field accepts numbers and text. The inserted
value has to be unique. It is possible to register companies without a VAT identification number.

Chapter 4
Language configuration
The translation of texts and codes is done in the Language configuration section.
4.1 Update an existing text
It is possible to edit existing texts in the Language configuration - Text screen.
To change an existing text, search for the text in the ‘Text’ field.
When the correct text is located, note the text number, e.g. 5512. Empty all the fields by clicking the Clear
button. Enter the number in the No field and click Select to get the text presented in all the available
languages. The text should always be updated for all languages to make sure the translation is consistent.
Update the description directly in the Text column.
4.1.1 How to find which text number to update?
If there are several texts that are exactly the same, do the following to find out which text to update:
• Update one of the texts

• Refresh cache, see if the text changed in the web application.
– If yes: Remember to translate for all languages.
– If no: “undo” the translation (to not destroy the other text). Try to update of the other texts
that are equal.
CHAPTER 4. LANGUAGE CONFIGURATION Page 51

4.2 Add a new text
Add new texts in the Language configuration – Text screen.
To create a new text select the Text Set ‘Customer specific texts’ and a Domain ‘Synergi Life Main application’
and click New. The domain ‘Synergi Life Main application’ represents the web application.
A new row for each activated language will appear.
• The text number (the column named “No”) will appear automatically when saving. Do NOT add any
text number manually.
• Enter the description in the column Text for ALL the languages. If you don’t know the translation add
the English text for all ‘untranslated’ languages.
• Select an appropriate text type for all rows. The text type is only supposed to help the administrator
understand what this text is used for. This can be very useful when there are similar texts used in
different places.
• Save.
Explanation of the columns in the Text screen:
• Text set
– The text set ‘Customer specific texts’ should always be used when an administrator or consultant
add new texts for the customer.
� Synergi Life development department uses ‘Synergi Life Main application’ for texts used in
the web application and ‘Synergi Life Administration application’ for texts used in the ad-
ministration application. These two Text Sets are preserved to be used by the development
department when developing new versions of Synergi Life. If someone else than the devel-
opment department add new texts to these two Text Sets this will cause a problem when
upgrading.
• Domain
– The domain ‘Synergi Life Main application’ which represents the web application should be used.
Synergi personnel should use ‘Synergi Life Main application’ for texts that are used in the web ap-
plication and ‘Synergi Life Administration application’ for texts that are used in the administration
application.
• No (text number)
– Do NOT enter any number. The text number appears automatically after saving.
• Text
– Enter the translation of the text in all the languages that appear.
• Text type
– The text type ‘Check box’ appears by default. Please change this to the appropriate text type.
This field is only for information purposes and does not have any effect otherwise.
• Original text
– The original text is the text which has been released by DNV GL Software. This can always be
used as a reference when changing texts several times. The original text cannot be changed by

the customer.
4.3 Add a new code in a codetable
All new codes have to be added into the Code administration section.
After a new code has been added, the description can be updated in:
• the Language configuration – Translation of Code Descriptions screen.

• the Code administration section.
See separate chapter about the Code administration for more information.
4.4 Update the description of a code in a codetable
It is possible to update the description of a code in the Code administration section. If you want to update
the code here, then you must first find the correct codetable screen where the code is used. See separate
chapter about the Code administration for more information.
In the Language configuration – Code descriptions it is possible to update the descriptions for all code
administration options. It is also possible to edit long descriptions for the codes that have long description.
There are many codetables and many codes in total. If you search for everything in the Translation of
Code Descriptions screen without limiting the search it will take some time before the result appears. If
you know which Codetable that needs to be updated, then search for this Codetable in the dropdown to
quicker get the search result. If you have many languages, then you can limit the search by only searching
for one language to find the code number that needs to be updated. Afterwards you can search for the
Codetable and Code number for all languages to be able to update the description for all languages.

Codetable dropdown

4.4.1 Change the name of a case type or the explanation of the case type
Each module and case type can have an explanation that makes it easier to understand what kind of cases
that should be reported. The administrators must ensure that all active case types have a suitable explana-
tion.
The explanation of the case type is shown when holding the mouse over the case type.
To change the name of a case type or explanation search for the codetable Application - Long description
in the Translation of Code Descriptions screen. Normally the codetable has the same name as the
description used in the web application, but the case type codetable is an exception.
Change the name of the case type in the ‘Description’ column.
Change the explanation of the case type in the ‘Long description’ column.
Example: Change the case type “Accident” to “Incident with actual consequences”
Search for Codetable=’Application – long description’ and Description=accident.
Search for the code number to find the name of the case type for all the languages (here: 20).
Enter the new name of the case type in the Description column. Remember to change the name for all the
languages. Click Save.

4.5 Update the name of a folder, screen or background text used
in the administration application
The hierarchy in the administration application contains “folders” and “screens”. Both can be trans-
lated/renamed in the Translation of Code Descriptions screen.
Example: Language configuration is a folder, while Translation of Code Description is a screen.
The texts inside the screens and the menu options are translated in the Texts screen.
Find the text numbers by activating menu option ‘Background text numbers’. Then open a new screen.

4.5.1 How to update the names of the screens in the administration application
The “screens” are “codetables” and can be translated in the Translation of Code Descriptions screen.
Select “Code table” in the dropdown. Search for the name of the screen that should be updated. The name
will be updated everywhere the screen is used. Here: Changing the description for the “Unit – type” screen
will change name both in the ‘Where and What’ folder and in the Action folder.
Language configuration - Translation of Code Descriptions
Search for Codetable in the dropdown and the Code number; update the name of the screen for all
languages.

4.5.2 How to update the names of the ‘folders’ in the administration application
The “folders” are “task nodes” and can be translated in the Translation of Code Descriptions screen.
Select “Task node” in the Codetable dropdown. Search for the name of the folder that should be updated.
Search for Task node in the dropdown and the Code number; update the name of the folder for all
languages.

4.6 How to export Texts and Code Descriptions to Excel
Many customers use Synergi Life in several languages. It is not necessary that the administrators can
translate all texts and codes to all languages themselves. The Texts and Code descriptions can be exported
to Excel, sent to a translation person/agency, and then the texts and codes can be imported back into Synergi
Life.
4.6.1 Text
Texts can be exported to Excel from the screen Language Configuration - Text in the administration
application. Search for the text to export.
As an example here, select language equals ‘English’ and click the ‘Select’ button to search.
Click the ‘Export’ button to trigger the export of all the data returned from the search.
Save the exported data as an ‘.xls’ file (of the type ‘All files’).

Open the file saved as an Excel file. Click ‘Yes’ if a warning message appears while opening the Excel file.
Example of Texts exported from the Synergi Life administration application into this Excel file:
It is possible to change the file format from ‘.xls’ to ‘.xlsm’ by saving the .xls file as type ‘Excel Macro-Enabled
Workbook’.

4.6.2 Code descriptions
Code descriptions can be exported to Excel from the Translation of Code Descriptions screen in the
administration application. Search for the codes to export.
As an example here, select language equals ‘English’ and click the ‘Select’ button to search.

Click the ‘Export’ button to trigger an export of all the data returned from search.
Save the exported data as an ‘.xls’ file (of the type ‘All files’).
Open the file saved as an Excel file. Click ‘Yes’ if a warning message appears while opening the Excel file.

Example of Codes exported from the Synergi Life administration application into this Excel file:
It is possible to change the file format from ‘.xls’ to ‘.xlsm’ by saving the .xls file as type ‘Excel Macro-Enabled
Workbook’.

Chapter 5
User administration
The administrator can define, control and administer user access rights and the user interface. The adminis-
trator can give access to one specific user, or give access to a role and then assign this role to several users.
It is recommended to create roles and give access to roles and then assign these roles for several users. It
is less administration work to update a few roles than to update many users. See chapter about access to
users vs roles.
Synergi Life provides these main user interfaces:
• Basic user
– The Basic user has access to simplified reporting and search functionality.
• Extensive user
– This is the standard user interface. Extensive users can process cases, perform advanced
searches and analyse data in Synergi Life.
• Mobile user
• Public User
– The Public user has access to screens with minimized complexity, both with respect to function-
ality and security (limited risk). It is possible to anonymously register sensitive cases to protect
the person’s identity.
See the User manual for information for Basic and Extensive users.
See the User manual for the Public user interface.
User access sections:
• User details
– User name, User Id, E-mail address, Language etc.
– Alternative ID
� It is possible that several IDs automatically is logged in as the same user. This is default
not active.
– Additional information
� It is possible to add extra information per user (e.g. Birth date or Employed in unit). This
is default not active.
• Authorisation
– Role
� Select role if needed. See chapter about access to users vs roles.
– Operation
� Give access to read, save, approve etc.
– Default values
� Set which values should appear automatically when creating a new case.
CHAPTER 5. USER ADMINISTRATION Page 64

– Access to screen
� Some screens require specific access to be visible. E.g. Only some users should see the
details for Injured Persons.
– Extended access
� Give write access to some case types for some units.
– Visible for fields
� Add the fields where the user should not be visible. Show for Person in charge? Show for
User responsible for action?
– Restricted access
� Give read access to some case types for some units.
– Notifications
� Send a message to the responsible user when the specified case type is forwarded to the
specified unit
– Access to administrate user group
� Give access to share favourites and to administrate users with a group.
– Access to assign roles
� Used when the central administrator is giving local/limited local administrators access to
assign roles to other users.
5.1 User – Details
• Name
– The name of the user that appears when searching for e.g. Person in Charge. This name must
be unique. There may exist more than one person with the same name in the same company.
To be able to distinguish the users apart from each other, the persons with the same name
must have some additional information in their name. Example: “John Doe (working in the HSE
department)” or “John Doe (working in Norway)”.
• E-mail address
– It is recommended that all the users should have a valid e-mail address. All the users that should

send or receive cases/actions to and from other users need to have a valid e-mail address. A
user with read only access does not need to have an e-mail address.
• Disabled
– Users with a date in Disabled field will no longer be able to log into Synergi Life. If the user
has a Disabled date in the future the user can log into Synergi Life until this date. To enable a
deactivated user: Remove the date in Disabled field.
• User ID
– The user ID is the log in name for the user. Each user must have a unique user ID. The User ID
appears in the header for existing users. See separate chapter about changing User ID.
• Password
– See separate chapter about password.
User type and group
• User type
– The user type can be Basic, Extensive, Public or Mobile.
• Main user group
– The access to the main user group defines which user groups the user should be able to select
as the current user group. This access is set up in the Property dialog in the screen Code
administration – User Group Administration – User group.
• Current user group
– This user group defines which codes the user should be able to select. Each user can change
this user group herself.
Unit, location and language
• Unit
– This is used for some searches. Each user can change the Unit herself.
• Location
– This is used when searching for “Cases for my location”. Each user can change the Location
herself.
• Default language
– The web application language for the user. Each user can change the language herself.
Read only fields that will appear in the header when they have a value
• Created
– The date when the user was created.
• Modified
– The date of the last user update.
5.1.1 Change User ID
The user ID is the log in name for the user. Many customers have a standard naming of User IDs. The User
ID can be changed if necessary.
When using domain authentication the exact matching username including the domain name must be used.
To be able to support multiple user authentication repositories avoiding conflicting user IDs. This design also
ensures that one user cannot be logged in as another user by mistake.
How to change the user ID: Find the user. Click on the Change user ID menu item.

The old User ID is displayed and a new one can be entered.
All User IDs need to be unique. The validation will fail if an existing ID is entered.
5.1.2 Password
Many users have single-sign-on and are logged directly into Synergi Life, these users do not need a password.
The users that login to Synergi Life manually with a User ID and a password need to get a password. It is
not possible to set a password at the same time as creating a new user. A new password can be given to an

existing user by using the Reset password menu. The password is not visible in the user administration
and it is hashed and saved in the database.
5.1.2.1 Password policy
By default, the password policy only requires that the password has 12 characters. The password policy
must be defined by a regular expression in the DB initialisation setting 108 Regular expression for
password validation.
In the web the administrator will see the password policy in Reset password (guide text 8118). If the
password policy in DB-ini 108 is changed, then the guide text 8118 must also be updated to explain the
current policy.
Here are some examples of regular expressions for password-validation:
• .{1,}
The password must have at least one character
• .{8,}
The password must have at least 8 characters
• .{12,}
The password must have at least 12 characters
• ̂(?=.*\d).{4,8}$
The password must be between 4 and 8 digits long and include at least one numeric digit.

• ̂[a-zA-Z]\w{3,14}$
The password’s first character must be a letter, it must contain at least 4 characters and no more than
15 characters and no characters other than letters, numbers and the underscore may be used.
A lot of regular-expressions for password-validation can be found on the net. The regular-expression is
executed while running in the .NET Framework.
5.1.2.2 How to force the users to change password regularly
It is possible to force the users to change password every XX days. This only applies to users that have a
password, which excludes users with single sign-on.
Activate the functionality by changing ‘DB Initialization setting’ 75 ‘Force user to change password’. Specify
the number of days a password is valid in the ‘Value’ column and check the box marked ‘Active’. Refresh
cache.
5.1.3 User Details - Unit and Location
Each user may have a value for Unit and Location. Users may update these fields themselves in User
profile.
There are some predefined searches:
• “Cases for my location”

– Searches for cases having the user’s location (or any child location)
• “Cases my unit is in charge of (aggregated)”
– Searches for cases having Unit In Charge equal to the user’s Unit (or any child unit)
• “Cases my unit is in charge of (not aggregated)”
– Searches for cases having Unit In Charge exactly equal to the user’s Unit (not any child unit)
• “Cases my unit is responsible for”
– Searches for cases having Responsible unit equal to the user’s Unit (or any child unit)
• “Actions my unit is responsible for (aggregated)”
– Searches for actions having Unit Responsible For Action equal to the user’s Unit (or any child
unit)
• “Actions my unit is responsible for (not aggregated)”
– Searches for actions having Unit Responsible For Action exactly equal to the user’s Unit (not
any child unit)
A user without any value in Location/Unit will get “all cases/actions” (that the user have access to read)
when using these predefined searches for My unit/location.
All searches include both open and closed cases/actions. It is possible to combine these searches with e.g.
“Actions in process” and “Cases in process”.

The user’s Unit does not have the same functionality as Notifications. There is no e-mails sent to the user
if a case/action is registered at the user’s Unit. (If the user is set-up to get Notifications for the same unit,
then the user will of course get an e-mail).
5.2 Authorisation - operation
The operations the user should be able to perform for different case types can be set in the Operation
section.
Example: This user has access to:
• HSE incident cases - read and save

• Quality management - Quality nonconformity - approve, read and save
Application / case type, operation and short explanation
• Case types
– Read
� The user will be able to read the case. The case will appear in searches performed by the
user. See the information about Restricted access.
– Save
� The user will be able to create new cases. The user will be able to edit the case if the user
has Extended access.
– Approve
� The user will be able to change the status to Approve and to change the status back to the
previous status.
– Delete
� The user will be able to delete the case.
– Case administrator
� The user can update fields that are usually read-only when the case is in the status Approve
or Closed. Users without case administrator access need to change the case status back
to a status before Approve (e.g. Registered, Processing) in order to be able to update the
same fields. A user with Case administrator access can also delete cases.
• Synergi Life Tools
– Administration - Central
� Central administrators can do changes in all screens in the administration application.

� The Central administrator controls the Limited / Local administrators‘ access.
– Administration - Local
– Administration - Limited local
– Delete
– Read
– Refresh cache
– Regenerate aggregate table
– Save
• Excel Add-In
– Mass update cases
� The user can edit cases and actions in Excel.
� The administrator should grant access to the specific case type where the user should be
able to edit cases/action in Excel.
• Export and import cases
– Export
� The user can export cases.
– Import
� The user can import cases.
• Synergi Life Tools - Scheduler

– Administer maintenances jobs
– Run maintenance jobs
Example of access operation:
• Synergi Life + Read

– The user can read all cases
• HSE + Approve
– The user can only approve HSE cases (Accident, Near Miss and Condition). The user cannot
approve Quality cases.
5.2.1 Approve access
To be able to approve cases the user needs access to the Approve operation. The user must also have Read
and Save access to the cases. If a user does not have access to approve a case, then the Approve status
will not be visible. But if someone else has approved the case, then the user may close the case.
It is possible to limit the user to only be allowed to approve certain case types with low loss potential, while
some users should be allowed to approve all cases. The loss potential is also known as the “traffic light” or
risk area:
• No risk area (no traffic light, no loss potential)

• Less serious area (green traffic light)
• Serious area (yellow traffic light)
• Critical area (red traffic light)
Explanation of users and Approve access with/without a criteria
Example 1:
• The user has access to ‘Synergi Life - Approve’ (and no further approve access).
• The user can approve all case types for all loss potentials (all traffic lights)
Example 2:
• The user has access to

– ‘Synergi Life - Approve - No risk area’
– ‘Synergi Life - Approve - Less serious area’
• Means
– The user can approve cases with no risk area and green risk area

Example 3:
• The user has access to

– ‘Synergi Life - Approve’
– ‘HSE - Approve - No risk area’
– ‘HSE - Approve - Less serious area’
• Means
– The user can approve all cases for all loss potentials, except HSE cases
– The user can approve HSE cases with no risk area and green risk area
5.2.2 Access to the application “Synergi Life” vs “Synergi Life Tools”
Giving a user access to “Synergi Life” means that the user has access to all case types.
Giving a user access to “Synergi Life Tools” means that the user has access to the administration, configura-
tion and special functionality.
5.3 Default values
Default values can be defined for different fields and case types. A user can only add default values for
case types that he has access to.
Add a new default value by selecting Option list, Case type, Default value and Field(s), then click Add.
Alternatively click Add another to add more default values.

Result: Unit ‘HSE & Quality’ will appear in Unit in charge, Unit responsible for action and Responsible
unit when creating new HSE incident cases.

5.4 Access to screen
The user can be granted access to different screens:
• Case log (XML)

– The case processing log contains a case log in an XML format.
– The administrator should grant access to the specific case type(s) where the user should be able
to view the case log.
• Injured person
– Information about the Injured person will appear in the specified case types.
– The administrator should grant access to the specific case type where the user should be able
to view information about Injured persons
• Involved person
– The Involved person section will appear in the specified case types.
to view Involved person
• Occupational illness screen
– The user will be able to edit the Occupational illness section for the specified case types. Users
without the Occupational illness section will be able to see the consequence in the consequence
table, but not be able to click at the link to edit the section.
to view the Occupational illness screen.
5.5 Extended access
Extended access provides the user with write access to existing cases.
• A user WITHOUT extended access

– can register new cases (assuming the user has access to the Save operation), but the user
can only change existing cases if someone else selects the user as Person in charge or User
responsible for action.
– can assign Unit In Charge, but is not allowed to assign Person In Charge.
• A user WITH extended access
– can edit cases of specific Case types and Unit in charge or Unit responsible for action where
the user has been granted Extended access. The user may also edit cases containing child case
types or child units. The user also needs to be granted Save access in the Operation.
– can assign both Unit In Charge and Person In Charge.

E.g. if the user is granted access to HSE incident cases, the user may also edit Accidents since this is a child
case type of HSE incident. Similar if the user is granted access to the ‘Administration’ unit then he may also
edit cases having Unit in charge that equals the ‘Administration - PO’ unit.
5.6 Visible for fields
Some fields in the main application allow the user to select other users from a list. In this section, the
administrator can control in which lists a user will be visible / hidden. Mark the fields where the user should
show.
Example: This user will not be visible in fields Person in charge, User responsible for action nor Sig-
nature. The user will appear in the list in Share case, so it is possible to send an email to inform the user
about the case. The user will also be visible in Synergi Life user (Involved person).

5.7 Restricted access
Restricted access provides the user with read access to existing cases. The user also needs to have Read
access for the case type in Operation.
• A user WITHOUT restricted access has no read restrictions and may read all cases.
• A user WITH restricted access can exclusively read cases of specific Case types and Units in charge
that the user has been granted restricted access to. The user may also read cases containing child
case types or child units.
E.g. if the user is granted access to HSE incident, the user may also read Accidents. Similar if the user is
granted access to the ‘Administration’ unit, the user may also read cases having Unit in charge that equals
the ‘Administration - PO’ unit.
Restricted access section is activated/deactivated by DB initialization setting 114 Restricted Access

- User/Roles.
5.8 Notifications
A user can be set as responsible for a specific unit for certain case types. This will allow the user to easily
find the cases involving his unit under the predefined searches ‘Cases in process for units I am responsible
for’ and ‘Actions in process for units I am responsible for’. The user will also receive a case e-mail if a new
case contains his unit and no Person in charge is selected. Similar for actions; the user will receive an
action e-mail if there is no User responsible for action. The user is also responsible for the child case
types and the child units, unless there are some other users responsible for the child case type or child unit.
The user also needs to have Extended access to all the units in Notifications in order to have write access
to the cases.

5.9 Access to administrate user group
• A user has Access to administrate a user group, and the user has ‘administrator access’ in Oper-
ation.
– This means that the user will be able to update all users having the specific user group as their
Main user group in User administration.
• A user has Access to administrate a user group, and the user has ‘read access’ in Operation.
– This means that the user will be able to share a favourite with all users having the specific user
group as their Main user group.
Example: A user has Administrator access and access to “Standard user group”, “Tripod” and “MTO”. This
administrator can modify all users having one of these groups as their Main user group.
5.10 Alternative ID
Alternative ID is used when several windows login users should automatically log in as the same Synergi Life
user. The alternative ID can only be utilized when single sign on is in use.
Example of when to use the Alternative ID:

There must, at all times, be a person that does the job as a platform manager, 24 hours a day, 365 days a
year. 6 people are working as a platform manager at a rig in the North Sea. 3 of them are at the platform
for 3 weeks, and then the other 3 people work for 3 weeks. The 3 people at the platform work 8 hours
shifts. When each person log in to the computer they have their personal windows login (to be able to have
some personal settings), but when logging into Synergi Life they should do the job as the platform manager
continuously. “My cases” is the cases of the platform manager, not the cases of Ola Normann or Kari Knutsen.
When using single sign on, it is possible to have several window login users as alternative ID so that several
window users log into Synergi Life as the same user.

The Alternative ID functionality was only intended to support persons working back to back, for example
offshore. In general Synergi Life does not support different persons logging in with the same user id on the
same time. Each person must have a unique user id.
Example of how NOT to use Alternative ID:

All 50 electricians at a platform should not log in with alternative ID as “electrician user”. Then it is possible
that several persons log in at different computers editing the same case at the same time, this may cause
problems. Instead all electricians should have their own user ID and have the same Role, then it is easier
to give them the same access and update the access (if needed to do changes this is only done once for the
role instead of 50 times for each user).
The Alternative ID section must be activated before using it. Activate DB Initialisation settings 115
Alternative ID, refresh cache, then the Alternative ID section will show up in the User administration.
5.11 Additional Information - Extra information for code tables
It is possible to add extra information for Users. Example: add address, phone number and birth date for
each user. This information is only visible when administrating users. The users cannot see the information.
Example: Go to Workflow configuration – Extra information for code tables.

Add Employed in company, Birth date and Phone to Users:
An extra section will appear in the user administration. It is possible to select Employed in company from
the company list, add birth date (this must entered in a date format), and add phone number (this must be
an integer).
Fill in the Additional information:

Example of how to use the Additional Information for Users:
It is possible to add ‘Employed in Company’ for all users. Then all users that are employed in the company
will have access to all cases, while the customers / external users that login can only see the cases where
their company is involved. In order to make this work it is necessary to set up a read criterion comparing
‘Employed in Company’ for the logged on user with ‘Company Involved’ for each case. Contact DNV GL
support to learn more about the possibilities.
5.12 Access to cases and actions
Users are given general access rights in the Operation section (e.g. Read, Save, Approve). These access
rights are given on case type level and are only valid for cases and actions that have been assigned to the
user.
It is possible to limit the user’s ability to only read cases of certain case types and units by giving restricted
access to the case type(s).
It is also possible to expand the user’s ability to edit cases/actions other than the ones the user has been
given access to directly by assigning extended access to case types and units.
5.12.1 Access to read a case
If a user should be able to read a case:
• The user needs to have Read access to the case type in the Operation section.
• …AND…
• The user must have no Restricted access OR the user must have Restricted access that includes
the case type. A user with Restricted access to case type C and Unit U can read a case if the case
is of the case type C and Unit in charge equals unit U. The user can also read cases with any child
case type of C and any child units of U.
5.12.2 Access to edit a case
If a user should be able to edit a case:
• The user needs to have Read access (see the necessary access information above)
• …AND…
• The user needs to have Save access to the case type in the Operation section
• …AND…
• The user needs to have Extended access to the case OR he needs to be Person in charge. A user
with Extended access to case type C and Unit U can edit the case if the case has case type C and
Unit in charge equals U. The user can also edit cases with any child case types of C and any child
units of U.
5.12.3 Access to edit an action
If a user should be able to edit an action:
• The user needs to have Read access (see the necessary access information above)
• …AND…
• The user needs to have Save access to the case type in the Operation section
• …AND…

• The user must have Extended access to the case OR he must be User responsible for actions. A
user with Extended access to case type C and Unit U can edit the action if the case has case type C
and Unit responsible for action equals U. The user can also edit actions when the case is any child
case types of C and any child units of U.
5.13 Give access to users vs access to roles
The administrator will save time by creating a role and then assigning this role to several users. It is likely
that all users that have “similar” access later will need less or more access; then it is quicker to update one
role than to update all individual users. In addition it is safer: If all “similar” users should get less access
and you have to update all users manually, then you may forget to update one of the users and the user will
have more access than she should.
5.13.1 How to assign a role to a user
The users can have a specific role assigned to them. Alternatively the user can have no role. The role is
assigned in the Authorisation.
5.13.2 What does it mean to assign a role to a user?
The following types of privileges can be granted to a role instead of directly to the user:

• Access to operation
• Default value
• Access to screen
• Extended access (write access to Unit in charge)
• Visible for fields
• Restricted access (read access to Unit in charge)
• Additional information
Each of these access types are represented as a separate section in the user administration. When the
user has a role assigned then the administrator must decide if the user should use Role based access or
Custom access per section.
• If the Custom access is used then the user specific access will apply for the user for this section.
• If the Role based access is used then the role’s access will apply for the user for this section.
NB! Privileges granted to a role and a user will not be merged.
If the administrator change from Role access to Custom access (or opposite) he must confirm switching
access:
Note that the personal default values will not be merged with the roles default values. If the user has no
personal default values in User profile then the default values of the role will be used. If the user has
personal default values in User profile, the default values granted to the role will not be used. If the user

wants to have the same default values as the role and some extra personal default values he must add all
of them as personal default values.
Example:
• The role has

– Access to Operation:
� Case type: HSE Incident
� Operations: Read and Save
– Extended access
� Case types: all
� Units: HSE, Marketing and Production
� Injured person
� Occupational illness
• The user should have access to:
� Operations: Approve, Read and Save
– Extended access
� Case types: all
� Units: Administration, HSE, Marketing and Production
� Injured person
� Occupational illness
• The user needs to be granted access to:
� Operations: Approve, Read and Save
� Since the user needs more access than the role, then also all the role’s access must be
granted specifically
– Extended access
� Case types: all
� Units: Administration, HSE, Marketing and Production
� Since the user needs more access than the role, then also all the role’s access must be
granted specifically
– No Access to screen
� Since the user needs the same access as the role then the user does not need to be given
any access here.

5.14 Duplicate user
To create a user similar to an existing user, Duplicate the existing user.
Access to operation, Default values, Access to screen, Extended access etc. are copied from the
original user. Fill out the Name, E-mail address and New user ID for the new user and click Duplicate
user.
A local/limited local administrator can only duplicate users he has access to edit.

5.15 Delete user
It is possible to delete users that have not been used.
Example of when a user has been used:
• The user has edited a case, this means that the user exists in the case log.
• The user is Person in charge or User responsible for action.
Delete user from the menu:
A message will appear confirming that the user has been deleted.
Trying to delete a user that cannot be deleted will result in an error message.
5.16 Search for users
When opening the User administration the administrator has a default Predefined filter excluding Inac-
tive users.
Remove this Filter to if you want to see both users with and without a Disabled date.
By default the search field in User administration searches for Name, E-mail address and User ID (and
Alternative ID and Alternative ID name if activated). Enter part of the name in the search field, the
result appear while typing.

It is also possible to search for users by adding Filters. The Filters in User administration works similar
as the Filters when searching for cases.
In the Filters it is possible to search for
• Predefined filters
– Inactive users
– Users in user groups administrated by me
– Users without email address
• Role
• Extended access
– Case type
– Unit
• Restricted access
– Case type
– Unit
• Notifications for units
– Case type
– Unit
• User type
• Access to operation
– Application or Case type
– Operation
• Access to screen
– Case type
– Screen
• Main user group
• Access to administrate user group

When checking ‘Ignore access inherited from the role’ the administrator will only search for users that have
custom access set directly at the user. The administrator will not see the users that inherit the access from
a role.
5.17 Search for roles
In Role administration it is possible to search for the name of the role. Type part of the role name in the
search field, the result appear while typing.

5.18 User with administrator access
An administrator is an extensive user with central-, local- or limited local administrator rights. The
code tables that local and limited local administrators can administer are defined in the Synergi Life
administration & configuration - Workflow administration – Administration type configuration. A
central administrator can administrate all the code tables in Synergi Life.
An administrator with access to the User administration cannot grant wider access to other users than the
user already has herself.
However, a Central administrator with the following access can grant more access to other users than the
user already has herself. This is the only administrator that can grant access to herself.
Access to Operation:
• Application:
– Synergi Life Tools - Synergi Life Administration & Configuration – User Administration
• Operations:
– Administration – Central
– Read
– Save
– Delete
All databases must have at least one Central administrator. It is recommended to have a restricted number
of central administrators. Additional administrators should have local or limited local administrator
rights.
Example of a Local administrator:

If the administrator should have access to the Administration application Synergi.exe, then the adminis-
trator need to have a database user. The menu option Create database user is available when the user
has administrative access to one of the following applications (or any of the parents or child applications):
• Reports
• Code administration
• Interface configuration
• Workflow configuration
• Language configuration
• Special reports, dashboards and favourites configuration
• System configuration (Synergi Life personnel only)
If the database user is not created, then the administrator will only be able to administrate from the web
application.
The password policy for the database user may vary. In the web the administrator will see the password
policy in Create database user (guide text 8119). If the password policy for the database is changed,
then it is recommended to also change the guide text 8119 to explain the current policy.

The password policy for the database user may be different than the password policy for the web application.
See separate chapter about password policy.
5.18.1 Restrictions for Local / Limited local administrators when doing User Ad-
ministration
If a Local or Limited local administrator should be able to do User administration she needs to have
access to:
• Application
– Synergi Life Tools - Synergi Life Administration & Configuration – User Administration
• Operations
– Save
– Read
– Local or Limited local administrator
The Local administrator controls the Limited Local administrators‘ access. A Limited local administrator
cannot edit a Local administrator.
A local / limited local administrator cannot be assigned a role, all the access must be given directly to the
administrator.

A local / limited local administrator cannot create a user that has more access than the administrator, or
update a user that has more access than the administrator. To be able to edit a user the local/limited local
administrator must to have:
• At least the same access to Operation.

– If the user has read + save access to all case types then the administrator must also have read
+ save access to ‘Case types’.
• At least the same Access to screen.
– The administrator must also have Access to operation = Read to the case type that she wants
to give in Access to screen.
• At least the same Extended access.
• At least the same Extended access as the edited user’s Notifications.
• No rows or at least the same rows in Restricted access.
– If the local administrator has any Restricted access he cannot create or edit users who has
Restricted access to a unit or case type higher up in the hierarchies.
– If the local administrator has no Restricted access he can create or edit users who has no
Restricted access or any combinations of Restricted access.
• Access to administrate user group to the user’s Main user group.
• Access to assign role to the user’s role.
– A local/limited local administrator will not be able to edit a user when he/she is assigned a
role that the administrator does not have rights to assign.
Example:
A local administrator has the following access:
• Operation:
– All case types: Read and Save
– Synergi Life tools: Administration – Local, Read and Save
• Extended Access:
– All case types: Production unit.
• Access to administrate user group
– Standard user group

This administrator can grant access to read and save at all levels in the case type hierarchy. The adminis-
trator can give Extended access to the Production unit and all child units. The administrator cannot grant
access to Approve, Delete, nor grant access to the Marketing unit (since this is not a child unit of Production).
The administrator cannot give any Access to screen since she has no access here herself. The administrator
can give any access in Restricted access since she has no restrictions here herself. The administrator can
only create users and update users having ‘Standard User Group’ as their Main user group.
5.18.2 Access to assign roles
The Central administrator decides which roles the local / limited local administrator can assign to other
users. The role itself may have more access than the local / limited local administrator. The local /
limited local administrator cannot change the role’s access, but they can assign the role to other users.
The local / limited local administrator must have Access to assign roles:
When the local / limited local administrator is editing a user’s access these roles appear in Authorisation:

5.19 How to set up default values for the users
Default value configuration is done in Default value configuration screens.
NB! Remember to run a RefreshCache after doing changes to any of these screens.
How does Synergi know if default values should be used?

Synergi always starts from the “bottom” in the case type hierarchy to search for Active / Not active to see
if the field should use a default value or not. This is done in the column Insert default value in the Default
value configuration per case type screen. If the column is –Not selected– for all the case types up in
the hierarchy Synergi Life looks at this column for a domain in the Default value configuration screen.
If the answer is Not active or —Not selected– default values should not be inserted, neither personal, per
case type nor per domain.
If the answer is Active Synergi Life looks for what default value to insert.
How does Synergi Life know what default value to use?

First of all Synergi Life checks if the user has a personal default value. Then Synergi Life checks from
the bottom and up in the case type hierarchy to see if a case type dependent default value exists, this is
done in the column Default value in Default value configuration per case type screen. At last Synergi
Life checks to see if a default value for the domain exists in the column Default value in Default value
configuration screen.
Example:
Ask until you get the answer Active or Not active:
• Is Insert default value Active / Not active for Accident?

• Is Insert default value Active / Not active for HSE incident?
• Is Insert default value Active / Not active for Case types?
• Is Insert default value Active / Not active for the domain?
If the answer is Not active or –Not selected– do not use any default values.
If the answer is Active start from the bottom again and ask until you find an answer:
• Does the user have any personal default value for Accident (or any case types higher up in the hierar-
chy)?
• Does Accident have any default values in Default value configuration per case type?
• Does HSE have any default values in Default value configuration per case type?
• Does Case Type have any default values in Default value configuration per case type?
• Does the domain have any default values in Default value configuration?
Insert the default value, if any, from the first hit in the line of questions.
Why configure default values?

It is time consuming to configure default values, but it saves the end user even more time when registering
cases, in addition to be more user friendly.
How to do the configuration as quickly as possible?

Decide which fields should be used as personal default values by checking Personal default value in
Default value for code table.
If Personal default value is checked in the Default value for code table screen the code will use a
personal default values if any. Remember to run a refreshcache after doing changes to this screen.

Set the Insert default value to Active / Not active as high up in the hierarchy as possible, letting all the
case types below be set to –Not selected-.
The top level of the hierarchy is the Domain, this can be set to Active / Not active in the Default value
configuration. Remember to run a refreshcache after doing changes to this screen.
If Do not display in user admin is checked in the Default value configuration it will not be possible to
set personal default values for the code. If the user already has personal default values for the code this
default value will not be used when Do not display in user admin is checked.
In the Default value configuration per case type it is possible to set Insert default value to Active /
Not active per case type. Remember to run a refreshcache after doing changes to this screen.

Default values for lists vs. hierarchical fields
In the Default value configuration and Default value configuration per case type it is possible to add
the default value. The values must be added by number. The number is found in the Code tables. It is easy
to find the number for Code tables that only consist of a list (e.g. Company and Observer). For hierarchical
code tables (e.g. Location and Unit) it is important to find the number in the hierarchy and not in the list.
This is because one item in the list may exist in several places in the hierarchy.
Example: Default value for Responsible Unit is code 1078, Reported by company is 427
To add default values to Responsible unit use number 1078 from the Unit-hierarchy
The default value for Responsible unit is NOT number 2 in Unit-list screen

For items in the lists there are only one number to select. Select number 427 for SuperCompany AS.
E.g. All the extensive users should be able to use personal default values for Location for all case
types.
Set Insert default value to Active in the Default value configuration.

Set all the locations in Default value configuration per case type to –Not selected–.
Notice that the Default value fields do not have any values. This means that for users that has a personal
default value this value is used, and no values are inserted for users that do not have any personal default
value. Run a refreshcache.
E.g.: Set up all Basic users to not use default values for case category for any case type except
for HSE-incident.
Set the Insert default value checkmark to Not Active in the Default value configuration.
Example: In general the Case category field does not use default values.
Set case category for all the case types in Default value configuration per case type to
–Not selected–, but set case category to Active for HSE-incident.

• Default value for HSE incident – Accident:
– If the user has a personal default value it should be used, otherwise use case category 1.
• Default value for HSE incident – Condition:
• Default value for HSE incident – Near miss:
Run a refreshcache.
5.20 Export the list of users to Excel
Export to Excel will open the current list of users in Excel. If not all users should be exported then limit
the user list by the search field on top and/or use the filters and then click Export to Excel.

Chapter 6
Dashboard Configuration
A dashboard is a screen showing several favourites at the same pages. The customers can create favourites
and dashboards themselves.
A few standard dashboards have been added, some of which are default dashboards and others that are spe-
cific to different supported modules e.g, environmental, risks, barrier and HSE. These standard dashboards
might not be suitable for all customers. Dashboards are individual for each company and adjustments might
be needed to suit their own definitions for different favourites (shown as graphs or tables in dashboards)
e.g., LTI frequency, TRI frequency, etc.
CHAPTER 6. DASHBOARD CONFIGURATION Page 99

6.1 Processing dashboard
Example: Processing dashboard with favourites: My cases by due date, My cases per risk area, Person
in charge not assigned, My actions, Actions my unit is responsible for, Cases my unit is in charge of.

6.2 Default dashboard

6.3 Give access to creating dashboards
The administrator that should create dashboards must have access to administrate Special reports, dash-
boards and favourite configuration (or a parent “case type”) in Operation in User administration.
The administrator must also have Access to administrate user groups to be able to share the dashboard
type with some/all user groups.
Example: A dashboard type is shared with user groups

6.4 Step by step example of creating a new dashboard
In this sub-chapter we will go thought all steps of how an example dashboard is created. The example
consists of one dashboard with two favourites.
6.4.1 Create a dashboard type
I create a new “Dashboard type”
I decide which User groups the Dashboard type should be visible for:
I decide which Users the Dashboard type should be visible for:

I decide which case types the dashboard type should be visible for.
Dashboard type visible for “Case types” means that a user having access to all the “Synergi Life” (top item),
“case types” or any of the child case types will see the dashboard.
Dashboard type only visible for “HSE” means that a user having access to all the “Synergi life”, “case types”,
HSE cases or Accident, Near Miss and Condition will see the dashboard, while a user that only has access to
Proposed improvements will not see the dashboard.
6.4.2 Create folder for all the dashboard favourites
I will create a folder where I can save all the favourites that are used for my example dashboard. I don’t
have to put the favourites in a folder, but as an administrator I have lots of favourites and it is easier to have
an overview if I organize them.

Create a new folder for the favourites that are included in the dashboard

6.4.3 Create 2 favourites to be used on the dashboard
Favourite – Open cases per case type per status

I want the cases in my company to be processed and closed. I want a favourite to highlight which cases
that are piling up. A heatmap showing open cases per case type per status will cover the need.
• Search for the predefined filter ‘Cases in process’

• Create a Selection Report. Layout type is Heatmap.
• Group by ‘Status’ and ‘Case type’
• Share the favourite with all user groups
• Give the favourite a name
• Write down the favourite number (to enter this number into the administration application later)
• Save the favourite in the newly created folder

Favourite – Action in open cases
I want the actions in my company to be processed and closed before the action deadline. I want a favourite
to show for each unit if the open actions are near the deadline.
• Search for the predefined filter ‘Action in process’

• Create a Selection Report. Layout type is ‘Table’.
• Group by ‘Action - Responsible unit’ and ‘Action due status’
• Share the favourite with all user groups
• Give the favourite a name
• Write down the favourite number (to enter this number into the administration application later)
• Save the favourite in the newly created folder
6.4.4 Connect Favourites and Dashboard type
Now I must connect the favourites and the dashboard type, and decide where in the dashboard each favourite
should be positioned.
Favourites used in dashboard type

The settings in Favourites used in dashboard type will be explained below, when the dashboard is showing
in the web.
Run Refreshcache to see the favourites in the dashboard.
Now the users will see the dashboard in Dashboards menu from the start-up page.

6.5 Summary of how to create a new dashboard
1. Create a new dashboard type in “Dashboard type” screen in the Administration Application
a. Decide who should be able to see the dashboard: User group, Visible, Case type, Person.
2. Create a folder in the search screen to save all the favourites used in the dashboard.
3. Create new favourites in the web
a. Use only Selection Report or Frequency Report

b. Save the favourite, write down the favourite number
4. Connect the favourite numbers with the dashboard type in the Favourites used in dashboard type
screen in Administration Application
a. Decide the order of how the favourites should appear in the dashboard (sequence, height, width
etc.)
5. Refresh cache
Now the users (that have access to the dashboard type) can see the dashboard in the list in Dashboards
menu from the start-up page.
6.6 Doing changes to existing dashboard types
All dashboards created in the web belong to a specific dashboard type. Dashboard types are configurable in
the screen Dashboard types and Favourites used in a dashboard type in the administration application.
Configuration changes for any dashboard type or its favourites will affect all the dashboards belonging to
that dashboard type which has undergone changes.

6.6.1 Change in Dashboard type
Disabled: This will deactivate associated dashboards from a specific date.
Sequence: The dashboards in the Dashboards from the start-up page in the web appear by sequence. If
there are no sequence then the sorting is alphabetically.
6.6.2 Change in Favourites used in dashboard type
We can change the content to any existing dashboard created in the web by adding or removing favourites in
the Favourites used in dashboard type screen. Favourites in this screen are added per dashboard type.
Settings you may want to change:
• Sequence is the order of the favourites in the dashboard.

• Min width of the favourite
• Height (pixels) of the favourite
• Disabled: This will remove the favourite from the dashboards of that type on a specific date.
NB! Run Refreshcache after doing changes in this screen.

6.6.3 Change search parameters or layout for existing favourites
An administrator cannot change the layout or search parameters to one specific favourite.
Steps to change the layout or search parameter for a favourite in the dashboard:
• Copy the existing favourite (by opening the favourite from the favourite menu or a link).
• Do the changes to the copy favourite.
• Save the copy favourite with a new favourite number.
• Copy the row for the old favourite in Favourites used in dashboard type, change the favourite
number to the new favourite, save.
• Remove the row for the old favourite in Favourites used in dashboard type.
6.6.4 Change the dashboard on the start-up page
The extensive start-up page uses Dashboard type “Start-up dashboard”. Each company may change which
favourites that are connected to the dashboard type.
It is possible to change which favourites or the order of the favourites on the start-up page in Favourites
used in dashboard type.
Run Refreshcache after doing changes in these screens.
Similar, the basic users use the dashboard type “Start-up dashboard for basic users”. This can also be
changed.
6.6.5 Explanation of difference between Alternative 1 and Alternative 2

favourites used for ‘Processing dashboard’
There are two standard different alternative favourites that can be used on the Processing dashboard.
‘Alternative 1’ favourites (219, 220, 224) are using Unit in the User profile.
‘Alternative 2’ favourites (227, 228, 229) are using Notifications in the User profile.
If Unit is used in User profile, then ‘Alternative 1’ favourites should be used, and disable ‘Alternative 2’
favourites.
If Unit is NOT used in User profile, then ‘Alternative 2’ favourites should be used, and ‘Alternative 1’
favourites should be disabled.
Rename the favourites you decide to use, remove the last part of the favourite name “ – Alternative x”.
The users of the web application does not need to know that there are two alternatives, the administrator

decides to use one of the alternatives.
6.7 What to check if the user cannot see the dashboard?
Here is a check list of what might be wrong if a user cannot see a dashboard.
Question / problem / possible solution
• Does the user’s read access to “case types” in access to Operation match to the “case types” Proper-
ties in “Dashboard type” screen in the administration application?
– The user may have access to the parent case type, same case type or any of the child case types
where the dashboard type is visible.
• Is the “Dashboard type” disabled in the administration application?
• Is the “Dashboard type” shared with the user’s “current user group”?
• Have you run Refreshcache after doing dashboard configuration?
– Run refreshcache and see if the dashboard appears.
• Is the “Dashboard type” visible for active case types?
– Some dashboards are only visible for some case types / modules. If the customer is not using
these case types, then the dashboards will not be visible in the web application. (Look at the
“Active” checkbox in System table Application)
6.8 What is limiting the content of the dashboard?
Here is a check list of what might be wrong if the content in the graphs/tables of a dashboard does not show
the expected result.
Limitation / problem / possible solution
• The Dashboard type has access mode “The content is limited by the user’s access”
– The user will only see cases that he has read access to
• A favourite in the dashboard has search parameters limiting the search

– The search parameters will limit the content of this graph/table
• A favourite is not showing in the dashboard
– The favourite might be disabled in Favourites used in dashboard type
6.9 Drilldown from favourites in dashboards
In the dashboard it is possible to click at the favourite header or parts of the result in the favourite to find
the search parameters for the favourite or the cases in the result.

By clicking on the favourite header the user will open a copy of the favourite
The copy favourite show the details:
• the type of report (here: Selection report)

• the Filters (the search parameters)
• the Visualisation (how to view the data)
– show the Group by domains.
– For graphs: (Here: the x- and y-coordinate are “Date and time” and “Counting cases”)
Copy of the favourite from drilldown

If the user clicks at parts of the graph or a row in the table she will get a Key facts or a Action headlines
view showing the cases/actions for that part of the favourite.
Drilldown by clicking at the graphs or table.
Read more about Drilldown from Selection report and Frequency report in the User manual.
6.10 Link to dashboard
It is possible to have link to a dashboard from the company’s intranet.
Example link: Replace <webserver>/<webapplication> with your normal link to Synergi Life.
Replace <dashboardNumber> with the Dashboard type number.
http://<webserver>/<webapplication>/dashboard/<dashboardNumber>/favourite/draft/
http://<webserver>/<webapplication>/dashboard/7/favourite/draft/
In the example the code number for the dashboard in Dashboard type screen is 7.
This link will open the dashboard number 7 “Processing dashboard”.
The link will open the dashboard directly if the company uses single-sign-on. The user will be asked for
user-id and password if the company do not use single-sign-on.

Chapter 7
Reports in the administration

application
The administration application provides three reports
• The Code table report contains an overview of the code numbers and descriptions.
• The Experience Transfer Report contains an overview of the cases where transfer of experience
e-mails have been sent.
• The Quality Control Report contains an overview of all the cases that have been registered at
approximately the same location, unit and time.
7.1 How to check for duplicate registrations of cases (Quality Con-

trol Report)
The purpose of the Quality control report is to reveal occurrences of cases that are registered twice. By
running the Quality control report all the pairs of cases within a XX minutes range between “Case date
and time” will appear.
E.g. two injured persons involved in the same car accident reports two different cases for the same accident.
This should result in one accident case with two personal injuries, not two cases.
The report can be limited by using 3 different “search parameters”: Case date (from and to), Location and
Unit. It is also possible to use a combination of the fields to limit the search.
By adding a “Date of case - From and To” the search will be limited to include double registrations within
this period only. For instance the administrator can do this once a month and search for the cases for the
last month.
By adding “Location” as a search parameter the search will be limited to include double registrations at one
specific location or its child locations only. Searching for “Norway” will display all the cases that have been
registered in Norway or any child location of Norway.
By adding “Unit” the search will be limited to only include double registrations for one Responsible Unit or
any child units.
Example of the Quality Control Report.
CHAPTER 7. REPORTS IN THE ADMINISTRATION APPLICATION Page 115

7.2 Code table report
The purpose of the Code table report is to give an overview of the code numbers and descriptions. These
reports are used when exporting data from one Synergi Life database and importing data into another Synergi
Life database. Example: Location ‘Europe’ may be code number 10 in one database, but code number 254
in another database.
Example of Code table report:
7.3 Experience Transfer Report
The purpose of the Experience Transfer Report is to give an overview of the cases where transfer of
experience e-mails have been sent.

Example of start page of report:
Example of content of report:

Chapter 8
Refresh cache
The settings in the database are cached when opening the web application. When changes are done to the
settings, the cache of the web application needs an update in order to show the latest changes.
8.1 When to refresh the cache
The cache needs to be refreshed when settings that will affect everyone, independent of user access, are
changed.
Examples of when it is necessary refresh the cache:
• Changing the position of a field

• Activating a new field
• Activating a new case type
• Changing the DB initialisation settings
• Activating a new criterion
• Changing special reports or dashboards.
Examples of when it is NOT necessary refresh the cache:
• Creating a new user

• Updating the access of existing users or roles (the user must only log off and on again to get the new
access rights)
• Adding a new code to a codetable like location, unit or company
• Modifying an import set.
In general changing any screen in these ‘Folders’ will need refresh cache:
• Workflow configuration
• Special reports, dashboards and favourites configuration
• System tables
General advice:
When performing an administration change, see if it appears automatically in the web application.
If not: run refresh cache and see if the change appears in the web.
8.2 How to refresh the cache
There are several caches that need to be refreshed:
• The refresh cache menu option in the web will refresh the web application (services).
CHAPTER 8. REFRESH CACHE Page 118

– This will refresh permissions of the users on front-end.
– This is needed to e.g. see case types that are newly activated
• There is also separate refresh cache endpoint for the scheduler.
8.2.1 Refresh cache for the web application
Run the Refresh cache from the menu to refresh the web application.
Figure 8.1: Refresh cache menu item
The menu option is only visible for a user with access to Operation = “Synergi Life Tools – Refresh cache”.
The user is informed when the caching is completed: ‘Cache has been refreshed’.
CHAPTER 8. REFRESH CACHE Page 119

Chapter 9
Workflow configuration -
Configuration for administrators
The purpose of this chapter is to explain the various configurations it is possible for the administrators to
do. This can be done without doing changes in the system tables, but it is not a part of the daily tasks for a
Central administrator.
CHAPTER 9. WORKFLOW CONFIGURATION - CONFIGURATION FOR ADMINISTRATORS Page 120

Name of screen and short explanation:
• Experience transfer configuration
– Link Experience transfer criteria – subscriber group

� This screen is used to tell who should receive a transfer of experience e-mail and when
should it be sent.
– Subscriber group
� A transfer of experience e-mail is sent to a subscriber group.
– Subscriber group members
� This screen tells which group of users / e-mail addresses that should receive a transfer of
experience e-mail
• Default value configuration
– Default value configuration

� In this screen it is possible to set up that a field should use default values. This will apply
to all case types.
– Default value configuration per case type
� In this screen it is possible to set up that a field should use default values. This will only
apply to the specific case type(s).
– Default value for code table
� This screen is listing all code tables. If a code table is checked for “personal default value”
all users might have a personal default value for this field, and the field is visible for the two
other “Default value configuration (per case type” screens.
• Criteria configuration
– Link Criteria Type to Operation and Input Form
� This screen tells for which operations it is allowed to send transfer of experience e-mails.
– Link Criteria and Operation
� This screen is used to set up
· transfer of experience e-mails
· insert “default values” by using InitialSave ExtraSql criterion
· updating fields on temp save by using TempSave ExtraSql criterion
· updating fields when saving a case by using SaveAsValid ExtraSql criterion
· limiting the access to the users by adding a Operation Criterion for Read-operation
– Link Criteria to Operation and Input Form
� This screen is used together with Link Criteria and Operation, but adds info about the
Input Form (extensive, basic or public)
• Connected cases configuration
– Connection type
� This screen decides how two cases can be connected; superior/subordinate, related, barrier
failed etc.
– Default filter connect case
� This screen decides which filters that appear when searching for an existing case to connect
to the current case.
– Default filter connect case - default values
� This screen decides which default values that should appear for the filters that appear when
searching for an existing case to connect to the current case.
– Information to copy
� This screen decides which fields that should be copied from the current case when creating
a new connected case.
– Visible case types for new case
� This screen decides which case types that is visible to select when clicking Add new con-
nected case.
• Notification configuration
– Alert configuration
� Link subscriber group to notification

· Connect Subscriber group and Notification
� Subscriber group
· A transfer of experience e-mail is sent to a subscriber group.
� Subscriber group members
· This screen tells which group of users / e-mail addresses that should receive a transfer
of experience e-mail
– Notifications
� The Notifications screen is used for setting up a reminder email to be sent out to the end
users.
· Example: Once a week the users should get an email about their cases and actions that
are about to expire.
� The Notifications screen is also used for creating Alert notifications.
• Administration Type Configuration
– In this screen it is possible to limit the access of Local / Limited local administrators
• Case Processing Configuration
– This screen decides “who should receive e-mail when” for different operations.
• Case registrations constraints
– In this screen it is possible to set up mandatory fields when saving or changing status of a case.
• Case status colour configuration
– Each status may have a colour. The colour is used in Selection Report and dashboards.
• Colours
– The colours are defined in RGB hex code (Red, Green, Blue). Each defined colour gets a descrip-
tion like for example “dark green” or “Purple”. The colours are connected to for example Case
Status and Action Status to visualize the status in the Selection Report and dashboards.
• DB initialization settings
– In this screen it is possible to change some database These are special settings that do not “fit”
into any other screens. Do not change anything here unless you know what you are doing.
• External URLs
– This screen is used for setting up URL’s to external systems. The URL can be changed by the
administrator, but the Code number for the URL still need to be connected to the domain with
configuration in the system tables.
• Extra information for code tables
– In this screen it is possible to define which extra information that should be available for users.
Example: Add Birth date, Employed in company, Phone number, Location of workplace. This info
is so far only available in the User administration, and the end users cannot see the info. This
info might be used to limit the access to the user, but this requires a special configuration.
• Administration of search index
– This screen is used to set up the “Search in all fields”; index search functionality. The settings
define how old cases that should be indexed.
9.1 How to set up a field as a mandatory field
All the fields in the case registration screen can be set up as a mandatory field. It is possible to set up a
field that is mandatory for the extensive case registration, but not mandatory for basic case registration or
import of cases. A field can be mandatory when approving a case, but not at first time registration. The
end user can be forced to fill out a field before saving the case, or get a warning message consisting of a
suggesting to fill out the field.
9.1.1 Remember the old cases when setting up a field as a mandatory field
When a field is set as mandatory this setting will also apply to existing cases. This might cause problems.
Example: If Equipment is set up to be a mandatory field when saving a case this will apply to all cases. A
normal user cannot edit any field in a case that is set to the status Approved or Closed, because all fields

are read only (grey). If the user wants to open the case again or send e-mail from the case, the user will
get a message that it is necessary to fill out Equipment before the case is saved, but the user will not be
able to save the case.
How to solve this problem

Alternative 1: Log in with a user that has access to “Case administrator”. Then search for all cases not
having a value in the new mandatory field. Then manually edit all the cases and select a value for the new
mandatory field.
Alternative 2: Get consultancy help from DNV GL. It is possible to update all existing cases and add a code
for all cases that does not have a value in the field.
For both alternatives 1 and 2 the code “This is an old case and this info is not available” might be added to
the old cases.
9.1.2 Where to set up field as a mandatory field – Case registration constraints
Setting up a field as a mandatory field is done in the Workflow configuration - Case registration con-
straints screen.
Location is mandatory field when saving Activity plan cases.
Error message that appears when trying to save an Activity plan without Location filled out.
Columns in Case registration constraints and short explanation:
• Root domain
– The root domain explains in which main screen the field is located. Used root domains:
� 469 Case registration extensive
� 1950 Case registration basic
� 1952 Action registration basic
� 5634 Public - Case registration
• Domain + description
– The domain and description is the connection to the physical field
• Operation
– This determines which operation the criterion should apply to. E.g. is the field mandatory when
saving the case or when approving the case
• Case type
– This determines which case type(s) the field is mandatory for. Case type 4 equals all case types.
• Import constraint set
– It is possible to have different constraints when importing cases from external systems.
• Criteria
– The criterion is the sql statement that runs in the background to check the value in the database.
Criteria cannot be created by customers themselves. Contact support to get a new criterion.
• Criteria response type

– There are two options: Stop and Warning. ‘Stop’ will force the end user to fill out the field before
saving (or approving) the case. ‘Warning’ will trigger a message to suggest that the field is filled
out, but it will be possible to save the case without filling out the field.
• Active
– There are two options: Activated or deactivated. If activated the criterion will run when saving
the case. If deactivated the criterion will not run.
• Text set, Text + description
– This is the error/warning message shown to the end user when the field is not filled out.
• Required
– This displays the asterisk for the field in the web application if checked. For the standard Synergi
Life criteria a required field asterisk is added if the field is always mandatory. If the field
is conditional mandatory, i.e. depending on selections done in other fields, an asterisk is not
added. Fields that are conditionally mandatory will be highlighted and an error message will be
displayed, but the asterisk will not be visible.
9.1.3 Example of setting the “How revealed” field as a mandatory field
The How revealed field will be set up to be a mandatory field for the case type Proposed improvements for
extensive case registration.
Find the field in the domain hierarchy.
Click on the button to open the hierarchy. Enter the name of the field; “how revealed” (remember
that it is possible that the field has one name shown to the end users in the web application and a different
name in the domain hierarchy).

Click on the search button to find all the domains with this name.
Double click on the correct domain. In this example; double click at domain 117 that is a part of the Case
registration extensive.
The correct domain will be selected in the hierarchy. Click OK.
Click Select to check if this field is already mandatory for any case types. In this case; no rows appear
because the How revealed (domain 117) is not mandatory for any case types.
Since no rows where found it is necessary to check if a criterion exists that can be used to set the How
revealed field as mandatory.
Try to find the criterion by searching for parts of the field name in the Translation of Code Descriptions

screen.
Select Criteria in the Codetable drop down list, type parts of the field name into the Description field and
click Select.
Usually the standard criterion has the same name as the field, but they are not always identical. Remember
to search for parts of the field name.
Example 1: The field “Work process” in the web application has a criterion named “Process”.
Example 2: The field “Company” in the Personal injury screen has a criterion named “Personal injury –
Company”.
If no rows appear it is likely that no criterion exists. All the available fields in case registration do not have
a standard criterion. Contact support for a consultant to create a customer specific criterion.
In the example with the How revealed field: A consultant creates the criterion.
Create a new text message that should be shown to the end user reminding the user to fill out the field (this
is done in Language Configuration – Text).
Return to the Case registration constraints to connect the criterion to the field.
Create a new row with the following set up:
• Case type = Proposed improvement

• Domain number = 117 found above
• Operation = Save
• Import constraint set = –Not selected– (explained in a separate chapter)
• Criteria = How revealed
• Criteria response type = Stop; since the user should be forced to fill out the field before saving the
case
• Active = checked
• Text set and text = Customer specific text, in this example text number is 1.
9.1.4 How to set up mandatory fields in the registration screen or when import-
ing cases from other databases
Cases are added to a company’s Synergi Life database in several ways e.g.
• Extensive users adding cases manually.

• Cooperation with 3 other companies where cases are imported from them to learn from their experi-
ences.
• Importing economic data from their economy system.

The cases that are added manually by extensive users need to have many mandatory fields. These fields
are set up having —Not Selected– as the Import Constraint Set.
The cases that are imported from the 3 other companies need to have fewer mandatory fields than the cases
that are added manually. These cases are just for information purposes and should not be processed. The
other companies often do not have the same fields as mandatory fields in their databases. Use the Import
Constraint Set = Import.
The data imported from the economy system need to have less mandatory fields because these cases need
to be manually checked and verified by a person in the economy department before closing the case. Create
a new Import Constraint Set called “Import from economy system”.
Set up one row for each field that should be mandatory for each Import Constraint Set, this is done in the
Case registration constraints screen.
Example: The Case Category field is mandatory when adding cases manually and when importing cases
from the other companies. Case category is not mandatory at the moment when importing data from the
economy system. When an extensive user starts to edit a case originally supplied by the economy system
the user will be in “extensive mode”. The rules for mandatory fields that will be used are retrieved from the
Import Constraint Set = –Not selected–, and the extensive user must fill out all fields that are mandatory
in the same way as adding a new case manually.
The company starts to cooperate with a forth company with less mandatory fields than the other 3
companies. They create a new Import Constraint Set “Mandatory fields when importing from company
D” with less mandatory fields. They connect the new Import Constraint Set to the Import Set for company D.
9.2 Default value configuration
The Default Value Configuration is explained in a separate chapter in the User Administration.

9.3 Extra information for code tables
This is explained in a separate chapter in the User Administration.
9.4 How to set up transfer of experience
If a criterion is fulfilled a Subscriber group will get a transfer of experience e-mail concerning a case. A
transfer of experience e-mail will only be sent once per case per operation. Example: One subscriber group
will only get a transfer of experience e-mail the first time the case is approved. If a case is approved a
second (and third and fourth time) there will not be sent any new transfer of experience e-mail to the same
subscriber group. However the same subscriber group can be set up to receive a transfer of experience
e-mail if the status has been changed to “closed” for example. One person can be a member of many
Subscriber groups. Many Subscriber groups can get an e-mail for the same criteria. If there is only one
person that should get a message, he needs to have defined his own Subscriber group with only him as a
member.
9.4.1 Short list of the steps to go through to set up experience transfer
Below is a short list of keywords for remembering all steps to go through when setting up a transfer of
experience. The following subchapters contain detailed explanation and examples.
• Determine when the experience transfer should be sent

– For what case types should the criterion apply?
– Should the e-mail be sent when the user first registers the case or when the case is approved?
– When should the e-mail be sent? E.g. when someone registers a personal injury? When someone
approves a case with a gas leak? When someone registers a case with critical (red) loss potential
in the location Stavanger?
• Find out if the needed criterion is a predefined criterion in the standard version in Synergi Life.
– If it is not: Contact Synergi Life Support and ask for an estimate of the price.
• Set up the criterion in the Link Criteria and Operation screen and Link Criteria to Operation and
Input Form screen.
– First: Add row in Link Criteria and Operation.
– Second: Add row in Link Criteria to Operation and Input Form. The same case type and
operation as in Link Criteria and Operation must be used.
– These two tables could be done before or after creating the subscriber groups and adding sub-
scriber group members.
• Create subscriber groups and add subscriber group members.
– First: Create groups in the Subscriber group screen.
– Second: Connect a User with an e-mail address or a separate e-mail address (not necessary
connected to any user) to the subscriber groups in the Subscriber group members screen.
• Connect the Criterion and subscriber groups in the Link Experience Transfer criteria – Subscriber
group screen.
– This must be done after setting up the criterion and creating the subscriber group. You must
have been through these screens:
� Link Criteria and Operation
� Link Criteria to Operation and Input Form
� Subscriber group
• Run refreshcache.
General settings for experience transfer
• Determine if an Anonymous transfer of experience user should be used.

• Check that e-mail will actually be sent. This is done in the Case Processing Configuration screen.
Below is a long explanation of the steps to set up transfer of experience e-mail.

9.4.2 How to activate a criterion for transfer of experience
Follow the next steps to activate a criterion.
9.4.2.1 Link Criteria and Operation
Go to the Link Criteria and Operation screen.

If a case type, an operation and a criterion match a specific operation will be carried out by the application.
These criteria are linked together in this screen.
A separate row for each operation and each criterion has to be created in order to connect a case type to an
operation and other criteria. In simple words: It will be defined that something shall happen but not what
shall happen.
Click New and choose what case type the criterion should apply to.
Choose operation. For example operation ‘Save’.
The experience transfer e-mail will only be sent once for each operation.
Example: Experience transfer e-mail will be sent for operation Save when a user registers an incident with
a gas leak. The e-mail is only sent at first time someone saves the case. The subscriber group members
will not receive a new e-mail each time the case is updated.
If the needed operation is not found in the list, please contact DNV GL Software for assistance.
Criteria type will appear automatically when saving the row (after refreshing the page).
Choose criteria number, and the criteria name will appear in the next column, or choose criteria in the
alphabetically list and the number will appear in the previous column.
Check Active to activate the function.
It is not necessary to consider column Def.active (default active). It is only used by DNV GL Software to
define if a criterion should be default active when creating a new database.
9.4.2.2 Link Criteria to Operation and Input Form
Go to the Link Criteria to Operation and Input Form screen.
Click New and choose what case type the criterion should apply to. The case type needs to be the same as
the one that was selected in the Link Criteria and Operation screen.
Choose operation. The operation needs to be the same as the one that was selected in the Link Criteria
and Operation screen.

Criteria type will appear automatically when saving the row and refreshing the page.
Choose Criteria from the list.
Choose Input form from the list. Input form could be basic, extensive or import.
Check Active to activate the function.
It is not necessary to consider column Def.active (default active). It is only used by DNV GL Software to
define if a criterion should be default active when creating a new database.
Sequence, the order of the criteria. The Sequence should normally be set equal 1.
Text set is normally set to Synergi Life Main application or Customer specifics texts. (The text that
should appear in the message needs to be defined in Language Configuration - Text screen.) Choose
text number, and the text will appear in the next column.
If the reason for setting up the criteria is experience transfer e-mail, no Text set or Text should be selected
since the user should not receive any message.
9.4.2.3 Link Criteria Type to Operation and Input Form
Go to the Link Criteria to Operation and Input Form screen.
Check if a row already exists with the operation and input form experience transfer should be set up for. If
not, create it. Otherwise no experience transfer e-mails for that operation and input form will be sent.
Choose Operation, Criteria type and Input Form. Check the Mandatory field.
9.4.3 Subscriber group
Go to the Subscriber group screen.
Add a new Subscriber group or use an existing group.

9.4.4 Subscriber group members
Go to the Subscriber group members screen.
All the Subscriber group members need to have a valid e-mail address so they can received the Transfer
of experience e-mails (TOE e-mails). A TOE e-mail can be sent to any e-mail address; internal or external
e-mail addresses, users or persons that are not users of Synergi Life.
It is recommended to add a User if there exists a user with the e-mail address that should receive the TOE
e-mail. If the user changes his e-mail address, then the new e-mail address will automatically also work
for the Subscriber group members. If there is person that should receive TOE e-mails that is not a user
in Synergi Life, then manually add a row with Subscriber name and an E-mail address. Each row should
either have a user with valid e-mail address, OR a Subscriber name and an E-mail address.
9.4.5 Link Experience transfer criteria – Subscriber group
Go to the Link Experience transfer criteria – Subscriber group screen.
Before creating a row in this screen the corresponding rows must have been created in the screens Sub-
scriber groups, Link criteria and Operation and Link criteria to Operation and Input form. The case
type in this screen must be the same case type as the two previous screens. If this is not done correctly the
following error could appear when trying to save the row:
Here you connect Subscriber group, input form, case type, criteria and operation. In this example the Gas
leak Subscriber group will get an e-mail each time somebody save or approve a case in extensive (with any

case type) which has criteria Gas leak.
9.4.6 Case Processing Configuration
Go to the Case Processing Configuration screen.
Here it is necessary to set what kind of message the Subscriber group should get when the criterion applies.
The operation is Transfer of experience.
Send e-mail must be set to Active to activate that the e-mail is actually sent when the criterion apply.
Text set e-mail subject is normally set to Synergi Life Main application or Customer specifics texts.
Here the text Transfer of experience from Synergi Life. <trans_title> will be sent to the receivers,
where the <trans_title> is replaced with the title in the case.
Choose Text e-mail subject number and the text will appear in the next column. (The text needs to be set
in Text in Language Configuration if it doesn’t already exist).
The Case Processing Configuration screen is hierarchical. If one case type has Send e-mail set to –Not
Selected–, then it will get Active / Not active from the parent case type.
To have all case types to be able to send transfer of experience e-mails set Send e-mail to Active for
Synergi Life case type, for all other case types set –Not selected–.
To have all case types except for one to send transfer of experience e-mails set Send e-mail to Active for
Synergi Life case type, and for the specific case type set Send e-mail to Not active.
In addition to having Transfer e-mail set to active it is also necessary to allow e-mails in general to be sent
when saving cases. For Operation Save for all case types the Send e-mail should be active.
9.4.7 Anonymous transfer of experience
The transfer of experience e-mails can be sent from the user saving the case or a common user depending
on setting in db ini 74 ‘Transfer of Experience user’. See separate chapter.
9.5 DB initialization Settings
The DB initialization Settings screen is found in Workflow configuration section. This is database
initialisation settings.
NB! If the settings in this screen are not familiar, do not change anything, as this can cause the
Synergi Life web application to crash.
All the database settings have a description and a long description explaining the functionality. The database
settings have a Section, this column indicates where in the application the setting is used.

9.5.1 Contact information
The Contact information at the bottom of the start page can either be an email address or a link.
If it is an email address this will appear with mailto:xxx@company.no when the user clicks at the email
address.
Note that for web URLs it is required to provide the protocol prefix in the db-ini setting (http:// or https://).
We cannot know what protocol the URL is hosted at. mailto: prefixes are added for the link if the db-ini
setting contains a @ character.
The email address or link is set in the Value-column for DB initialisation settings - 91 - Contact
information - email address or link.
9.5.2 How to change sender of Synergi Life e-mail
There can be several reasons why it can be desirable to change the sender of Synergi Life e-mails. Synergi
Life users can be intimidated when they find out that they trigger experience of transfer e-mails to the CEO

of the company or e-mail from Synergi Life can be trapped by SPAM filters or e-mail gateways. The sections
below describe how to configure Synergi Life to avoid these situations.
9.5.2.1 Sender of notification e-mails
The notification e-mails will be sent from the Synergi Life user indicated in DB ini setting 56 ‘Notification
person’.
Example: Activate DB ini 56 “Notification person”. Create a separate Synergi Life user that should send
the notification e-mails. Add the number of the Synergi Life user that should send the notification in Value
column in DB ini (here: 104).
9.5.2.2 Sender of transfer of experience e-mails
The transfer of experience e-mails can be sent from the user saving the case or a common user depending
on setting in db ini 74 ‘Transfer of Experience user’.
• DB ini 74 deactivated: The user saving the case will send the automatic transfer of experience e-mail.
• DB ini 74 activated: The Synergi Life user indicated in DB ini setting 74 will send the automatic transfer
of experience e-mail when the case is saved.
Example: Activate DB ini 74 “Transfer of Experience user”. Create a separate Synergi Life user that should
send the transfer of experience mails. Add the number of the Synergi Life user that should send the transfer
of experience in Value column in DB ini (here: 103).

9.5.3 Logging when users are reading case information
Synergi Life® supports logging when users are reading case information.
There are different levels of logging:
• Logging can be done when reading a case in:

– Case registration screen
– Case listings (e.g. Headlines, Key facts or Summary)
– Export
• To enable this logging activate db-ini setting:
– ‘99 - Log read access to cases’
� To log cases that are read in Case registration screen.
– ‘113 - Log read access to case listings’
� To read cases that are read in Case Listings or Export
Refreshcache.
The log is written to the database table X_SYSTEM_LOG with the following information:
• Case number
• Name and e-mail address of user reading case information
• Timestamp
Example: The Basic user read case 2989 in Case Registration Screen, and the Central administrator read
case 2996 in a case report.

9.5.4 Help menu with link to External URL
It is possible to activate a Help menu item with a link to an external URL.
This is done by activating DB-ini setting 112 ‘The external url type to use as help page’, and setting the value
to the code number in Workflow configuration - External URLs.
Example: code 50001 points to http://www.dnvgl.com
DB-ini 112 is activated, Value = 50001
9.5.5 How to make Name and E-mail address readonly in User Profile
If the company don’t want the users to be able to change their own Name and E-mail in User profile, then
activate DB ini 121 and 122.
DB Ini
• 121: E-mail in User Profile is read only

• 122: Name in User Profile is read only
Refresh cache.

Now the user must contact the administrator to get the Name or the E-mail address changed.
9.6 Administration Type Configuration
In this screen it is possible to set up which access the local / limited local administrators should have.
Example of which screens the Local Administration has access to.
• The local administrator can change the codetable Case category.

• The local administrator can not change Case processing configuration (and will not be able to
change the e-mail settings).

9.7 Case processing configuration
The Case processing configuration screen is about e-mail settings. The screen determines whether e-
mail should be sent or not, to whom the e-mails should be sent to, and what texts to add to the subject and
the body of the e-mail. The customers can change these settings themselves.
Explanation of the settings in the screenshot below:
• All actions closed

– The e-mail will be sent to ‘person in charge or persons responsible for unit’ (if active)
– But this e-mail is default not activated and will not be sent
Example of whom should receive e-mail
• E-mail to person in charge or persons responsible for unit

• E-mail to person on circulation list
• E-mail to registered by

9.7.1 How to ensure that the initial reporter receives an e-mail when the case is
being approved and closed?
All operations in Synergi Life can be attached to an e-mail criterion for each case type in the Case Processing
Configuration screen in the Workflow configuration section. Examples of operations are “Approve”,
“Close” and “Save”.
Select e-mail criteria in Case processing configuration.

Find the case type that should be connected to an e-mail criterion. Then choose one of the operations.
If the e-mail function related to a single case type and criterion should be activated/deactivated choose
“Active”/”Not active” in the Send e-mail column. Choose an e-mail criteria.
Mail criteria dropdown in Case processing configuration.
The case title is displayed in the e-mail subject.
The tag <TRANS_TITLE> is added to the texts used in e-mail subjects. If the organisation would like to
remove the case title in the e-mail subject it is necessary to create your own texts to be used as e-mail
subject texts. This can be set up in the Language configuration – Text screen.
9.8 Administration of search indexes
9.8.1 Index Search
9.8.1.1 General
All information regarding a case can be indexed to allow the users to search for words or phrases used in
any field in Synergi Life. Indexing will normally be performed on cases having case date within the last X
months. This will vary from customer to customer, according to the customer’s hardware capabilities and
the amount of data, and must be adjusted in db-setting 66.
The following types of data are indexed:
• description fields for cases (free text)

• code table descriptions
• number values
• date and time (limited)
All data for a case are concatenated into one string before indexing.
Code table descriptions for all levels will be used for hierarchy code tables.

Number values – integer and float – will be saved as strings. Floating point numbers will be saved using ‘.’
as decimal separator.
Date and time will be saved as strings using the following format - ‘2004-12-31’ for dates and ’13:25:00’
for time. Date and time will also be saved in one string using the following format ‘2004-12-31T13:25:00’.
Since the value is not saved as a proper date, it will not be possible to format the search string entered by
the user, i.e. the user cannot enter the date in local date format.
To limit the number of rows in the index table, a timestamp will be used to rule out data older than a specific
number of months entered as db-ini setting 66. A scheduled process will take care of deleting expired data.
During the process of indexing data the first time, it will be possible to disable the automatic deletion of data
using db-setting 63.
A scheduled process will rebuild search indexes for changed cases, code table descriptions and acti-
vated/deactivated languages. It will be possible to switch off the execution of either of these sub-processes
using db-ini settings 60. This can be useful when large reorganise operations are in process in the
administration application. Use this setting to avoid that the indexes are regenerated before the work in
process is done.
9.8.1.1.1 Expression parsing
Search expressions can be entered in a format similar to what is standard in most Web search engines
(Google and Bing).
Terminology:
• Phrase is a single word or several words enclosed by quotation marks (for example “12 inches
pipeline”).
• Operator is a reserved word and shows how to treat a single phrase (NOT) or the relationship between
phrases (AND, OR).
• Expression is the total amount of phrase and operators in an input string.
The following table shows the reserved words that can be used when building a search expression:
Operator Description
<space> See AND

+ See AND. + can be positioned just before a phrase (e.g. +hello)
or have spaces between it and the phrase (e.g. + hello)
AND AND between phrases means that all phrases must exist for a given case
for it to be included in search result.
OR OR between phrases means that on, several or all phrases
must exist for a given case for it to be included in search result.
NOT NOT is a phrase operator and indicates that a given phrase
should not exist for a given case for it to be included in search result.
- Same as NOT. – is preferred written without space between operator and phrase
(e.g. pipe –line), but spaces between – and phrase are also accepted (e.g. pipe – line).
Notice also that:
• A multiword phrase must be enclosed by quotation marks.

• Wildcard characters are not supported
• Parser is NOT case sensitive.
When parsing is done, parser expects an expression having the following syntax:
[<Phrase operator>]<Phrase>[<Phrase operator>[<Phrase operator>]<Phrase>]
where <Phrase operator> immediately before <Phrase> is NOT (or -) or nothing and <Phrase operator>
immediately before <Phrase operator> is AND (or <space>) or OR.

This expression is then split into AND separated strings, which are again split into OR separated strings
before values are written to database. This means that AND have precedence before OR.
Example:
Pipe AND pipeline AND broke OR busted

are split into
Pipe
Pipeline
broke OR busted
Where pipe is one search condition, Pipeline is favourite condition no. 2 and “broke OR busted” is favourite
condition no. 3, having broken and busted as 2 selection criteria values (OR’ed).
When an expression is interpreted, written to the database, read from database and then shown to the user
again, the shown expression might differ from what the user typed in, but the meaning of the expression is
the same.
Expression parser can be set up to include starting- and terminating quotation marks as a part of the phrase
when quotation marks defines a phrase, or it can return phrase without the starting- and ending quotation
mark if required. (This is controlled by expression class constructor.) Without quotation marks is default,
but in index search WITH quotation marks is used.
9.8.1.2 DB_INI-settings
Database Initialisation setting
• 60 Regenerate indexes for changed cases
– Default value: Active

– If Active, search index for cases will be updated for modified cases or cases marked to be
generated in the administration screen for search index.
• 63 Delete old cases
– Default value: Active

– If Active, search index for cases older than x months will be automatically deleted.
• 64 Number of cases in XML
– Default value: 10
– State number of cases that should be updated in the same operation when updating search index
for modified cases.
• 66 Build search index for specified number of months

– Default value: 12
– State how many months the search index should contain. Search index for cases older than
x months will be automatically deleted. Value = -1 indicates that all cases should be indexed,
i.e. search index data will not be automatically deleted.
• 67 Build search index based on (table column)
– Default value: D_TRANS.MODIFIED

– Possible other value: D_TRANS.TRANS_DATE
– State the name of the database column that will be used when generating and deleting indexes.
• 68 Average generation time (ticks) per case per language. One tick is 100 nanoseconds
• 119 Number of characters in search term must exceed specified value to apply wildcard search.
– Due to performance it is recommended to require more than 2 characters before wildcard search
is used
9.8.1.3 Tuning
Index generation times depends on the database server hardware, and will vary from customer to customer.
The best way to calculate total generation times is to do an initial run with a small data set, perhaps cases
for the last month. Afterwards, the db-setting 68 will contain the time consumption for generation of index
data for one trans per language (ticks). Use the following formula to determine total generation times:
Total number of transes * db-ini 68 = time (ticks)

Db-ini setting 64 tells how many transes to process simultaneously during index generation. Increasing
this number will dramatically reduce the time it takes to generate index data, but will at the same time
increase the memory needed. Take caution when increasing this number, and do steps upwards to monitor
the memory consumption and speed. At some point you will reach a point where the gain in speed is no
longer noticeable. This point may vary, but tests show that when increasing the number above 50 there is
little gain in speed, but a dramatic increase in memory consumption.
9.9 Case registration domains
The administrators can read information about the domains that are used in the case registration. Domain
number, Codetable, table name in the database, text and text set, xml tag etc.
Workflow configuration - Case registration domains.
Example:

9.10 Connected cases configuration
9.10.1 Visible case types for new case
The Visible case types for new case screen determines which case types that should be available when
creating a new connected case from a current case.
Example: Create a new Subordinate or Related case from an Audit plan:
Explanation of configuration:
• When creating a new Subordinate case from an Audit plan it is only possible to add an Audit
(selecting one of child case types Internal (first party), External (second party) or External
(third party)).
• When creating a new Related case from an Audit plan it is possible select any case type. The Audit
plan has no specific limitation for new connections here.
9.10.2 Information to copy
The Information to copy screen determines which fields that should be copied when creating a new con-
nected case from a current case. If the copy-from-field is a multiple-select and the copy-to-field is a single-
select, then just one of the item that appears will be copied.
Examples:

• When creating a new subordinate Audit finding from an Audit, then the fields Audit type, Work
process and Location will be copied.
• When creating a new subordinate Risk from a Risk assessment, then the fields Work process and
Location will be copied. The one of the units in Units involved will be copied to Responsible unit.
9.10.3 Connection type
The Connection type screen determines the relationship between two cases that are connected. The
customers may add more Connection types themselves.
9.10.4 Default filter connect case
When using Connect existing cases each Connection type has a set of default filters to try to find the case
to connect. The default filters are setup in Workflow configuration - Connected cases configuration -
Default filter connect case.
The default filters for Case types apply for all case types unless the child case type(s) has specific default
filters.
9.10.4.1 Default filters connect case - subordinate
The default filters when searching for a case to connect as subordinate case is ‘Cases in process’, ‘Modifed
date = Last 11 months and this month’ and ‘Responsible unit = ’My unit’.

Configuration for default filters for subordinated cases:
9.10.4.2 Default filter connect case - duplicate
When trying to Connect existing cases as a Duplicate we use the same default filters as Check for
possible duplicate registrations.

In case registration it is possible to Check for possible duplicate registrations. See further explanation
in the User Manual. The link itself need to be activated for one or several case types by a consultant.
When the user clicks the link he will get a search with some default Filters to try to find similar cases.
Here: The default filters that appears will copy the current case type, but search for the case type at level 3
(HSE Incident instead of Accident). The default filters search for the date from the current case. The default
filters search for the same location as the current case. If the Location for the current case is at level 1, 2
or 3, then the filter will search for the exact same Location. If the Location for the current case is at level 4
or lower in the hierarchy, then the default filters will search for the Location at level 3.

9.10.4.3 Default filter connect case - barrier connection types
When using Connect existings cases for any of the ‘Barrier…’ connection types it is very likely that this
case type should be any of the Barrier cases:
The default filters will search for case types that are Barriers:

The configuration is done by adding a filter for domain 100 Case types in Default filter connect case:
In addition the default values to search for must be added in Default filter connect case - default filters:
Case types 227, 248, 249 and 250 are Barriers.
9.10.4.4 Default filter connect case - connect current case to any case in bowtie
By clicking the button Connect to bowtie, the user can open any related bowties from the list of displayed
Top events. Any of the included cases in the bowtie can be connected to the current case. The field
Hazardous events involved in the current case has to be filled out before the list of Top events can be
displayed.
This is setup in Default filter connect case. Notice that values for domain 12119 is copied from current
case to search for domain 11099: Hazardous events involved -> Hazardous event
The default value 6 for ‘Top event’ is Default filter connect case - Default values:

Chapter 10
Special reports, dashboards and

favourites configuration
10.1 Case and action reports
The Case and action reports determines which fields that are visible for the different report types.
Example of fields showing for the Headlines.
CHAPTER 10. SPECIAL REPORTS, DASHBOARDS AND FAVOURITES CONFIGURATION Page 151
10.2 Default fields for reports
10.2.1 Default distribution options
The Default distribution options are the suggested case types that show up as distribution for the Fre-
quency Report.
10.2.2 Default filter domains
The Default filter domains are the domains that show up as suggested search fields in the search page.
There are 3 possible ways to have default search values. It is probably best to use one of these, and not all
3 at the same time as in this example:
• If there is a Default value, then this will appear in the search

– The value to be used as a Default value must be retrieved from the hierarchy if the codetable
is hierarchical
� In the screenshots below ‘Norway’ has code number 9 in the Location - hierarchy. The
value is NOT retrieved from the Location - list.
• If Use My Value is checked, and the user has a value in the Unit/Location in User profile, then My
value will be used as a default search value
• If a date field have Fixed period then this will appear as the default search value
Example:
10.2.3 Default selection group by domains
The Default selection group by domains are the domains that show up as suggested ‘group by’ fields for
‘Selection report’ and ‘Frequency report’.
Suggested ‘group by’ domains for ‘Selection report’:
10.2.4 Default selection quantify domains
The Default selection quantify domains are the domains that show up as suggestions for how the data
can be aggregated for ‘Selection report’ and ‘Frequency report’.
Suggested how to quantify domains for ‘Selection report’:
10.2.5 Default target applications
The Default target applications are the domains that show up as suggested as Targets for ‘Selection
report’ and ‘Frequency report’. The applications must also be activate to show in the web application.
Suggested target domains for ‘Selection report’:
Chapter 11
FAQ – Frequently asked questions /

Other functionality
The following chapters contain answers and solutions to the most frequently asked questions by Synergi Life
Administrators.
11.1 How to configure and in which order?
To configure a new database, start with configuring the System Tables, then Language, Case Processing
and so on. In other words - work from the bottom and upwards in the structure.
On the other hand, when administrating a database that is in use you will work mainly with the tables in the
upper part of the hierarchy:
• Case types
• Reports
• User Administration
• Code Tables
11.2 Can the date/time set-up be changed to 24/12, am/pm,

mmddyy or ddmmyy?
Yes, but not directly in Synergi Life. The date- and time format in Synergi Life follows the set-up on your
personal computer, and can be changed in Options in the control panel.
11.3 How to remove a value in a hierarchical field (Eraser button)
This example illustrates the use of the Eraser button in the Indicator Factor screen, but can be used to
remove the value in all hierarchical fields. In the Indicator Factor screen there are several fields that
can be used as search parameters to find the rows in the table. It is possible to remove all of the search
parameters by clicking “Clear” button. If the administrator wants to do a similar search then he does not
have to remove all the search parameters. The dropdown field can be emptied by selecting none of the
values in the dropdown. The hierarchical fields can be emptied by opening the dialog box and clicking the
Eraser button.
CHAPTER 11. FAQ – FREQUENTLY ASKED QUESTIONS / OTHER FUNCTIONALITY Page 159
Example: 3 of the fields have search parameters.
The value can be removed by clicking the button to open the dialog box and then click the button.
Click the browser button and then the eraser button to clear a value.
The Location search parameter is gone.
11.4 How to add messages to the users
In the Message to users screen it is possible to add messages that will appear when the users log into
the web application. The Active messages will appear untill the user have clicked Mark as read. The not
Active messages will not appear for the users. The Created date is when the message was entered into the
administration application. The message will show in the web application almost immediately after adding it.
The user will see the messages below the header.
The user can see both read and unread messages in Messages screen.
The message also support valid links using a protocol in the url: http://, https://, ftp://, ftps://, file://
Example: Message to users with URL:
Example: The link will open in a new tab:
11.5 Environmental management module administration
See the separate Environmental Management Module document for how to administer this module.
11.6 Menu option Grant
In the File menu in the administration application there is a Grant option. The Grant function creates Synergi
Life roles if they do not exist and grants the necessary database Object and System Privileges to the Synergi
Life roles.
11.7 Risk Matrix Configuration
See the separate Risk Matrix Configuration document for how to set up risk matrixes.
The following code tables are involved:
• Risk area
• Severity
• Recurrence [optional]
• Likelihood [optional]
• Risk matrix
• Consequence type
• Consequence severity
• Consequence recurrence [optional]
• Consequence likelihood [optional]
• Risk matrix configuration per case type
• Risk matrix type (system table)
Depending on the selected risk matrix type(s), the appropriate code tables must be configured properly
before using risk matrix.
11.8 How to copy Responsible unit to Unit in charge for new cases
By using a TempSave criterion it is possible to set Unit in charge to the same unit as Responsible Unit,
for new cases. To enable this feature the criteria must be activated.
Activate criteria ‘Copy responsible unit to unit in charge’ in the Link criteria and operation screen:
The criteria can also be turned on/off for different input forms in the Link Criteria to Operation and Input
Form screen:
If there is a default value for Unit in charge the default value will be inserted instead of copying Responsible
unit. The default value might be personal (per user), per role, per case type or per domain.
11.9 Missing users in “Person in charge” dialog
Problem: No users appear in the “Person in charge” dialog

Possible solutions:
• First select the Unit in charge, then open the dialog to select Person in charge.
• The logged on user does not have access to select Person in charge for the current Unit in charge.
Either the case must be saved without a Person in charge, or the logged on user must get Extended
access to the current case type and current Unit in charge.
Problem: One user is missing in “Person in charge” dialog

Possible solutions:
• The user or the user’s role must have Read and Save access to the case type. This is set in access to
Operation.
• The user or his role must have no Restricted access, or have Restricted access to the current case
type and Unit in charge.
• The user or his role must be visible for Person in charge. This is set in Visible for fields section in
the User Administration.
11.10 Administration of scheduled reports
Administration of scheduled reports
The scheduled reports are set up from the web application. But the three columns in Favourite screen will
enable administrators to:
• Add Recipients
• Change Report Language
• Remove the execution schedule
11.11 How to unlock locked cases (SynergiLockedCases.exe)
Only one user can edit one case at the time. If another user tries to edit the same case he will be informed
that the case is locked. A case is locked by a specific user when the user clicks Edit case. The case
is unlocked again when the user clicks Save or Discard changes. All cases that have been locked for
more than X hours will be unlocked again by the Scheduler. If a case has to be unlocked immediately, the
administrator can achive this by using the application SynergiLockedCases.exe.
The purpose of SynergiLockedCases.exe is to change “locked by user” for a specific case from one user
to another user. The new user can then open the case in the web application and decide to Save or Discard
the changes.
• SynergiLockedCases.exe must be run from the same folder as the administration application
(Synergi.exe).
• The login is the same as for the Synergi.exe file.
• Enter: Database, User, Password and DBO. Click Connect.
• Enter Case number that you want to unlock. Click Check Case (to confirm that it is the correct case
you are changing).
• Enter the UserID to the user that should open the case in the web application, in Locked by field.
– The new UserID can be the administator or some other user that should unlock the case.
– Click Change.
• Log into the web application and open the case, Save or Discard the changes.
• Now the case is unlocked.
Example: Case 2988 was locked by User ID ‘MNG’. This will now be changed to be locked by ‘CENTRALADMIN’
About DNV GL
DNV GL is a global quality assurance and risk management company. Driven by our purpose of safeguarding
life, property and the environment, we enable our customers to advance the safety and sustainability of
their business. Operating in more than 100 countries, our professionals are dedicated to helping customers
in the maritime, oil and gas, power and renewables and other industries to make the world safer, smarter
and greener.
Digital Solutions
DNV GL is a world-leading provider of digital solutions for managing risk and improving safety and asset
performance for ships, pipelines, processing plants, offshore structures, electric grids, smart cities and more.
Our open industry platform Veracity, cyber security and software solutions support business-critical activities
across many industries, including maritime, energy and healthcare.

Synergi Administration Manual

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Synergi Administration Manual

Uploaded by

Copyright:

Available Formats

A M

SAFER, SMARTER, GREENER

Prepared by DNV GL – Digital Solutions

© DNV GL AS. All rights reserved

1 Introduction to the administration application 5

2 Information for new administrators 14

7 Reports in the administration application 115

8 Refresh cache 118

9 Workflow configuration - Configuration for administrators 120

10Special reports, dashboards and favourites configuration 151

11FAQ – Frequently asked questions / Other functionality 159

Introduction to the administration

Synergi Life Administration Application Synergi.exe

The administration application is constructed as a logical hierarchy.

CHAPTER 1. INTRODUCTION TO THE ADMINISTRATION APPLICATION Page 5

Example of Location Hierarchy code administration.

CHAPTER 1. INTRODUCTION TO THE ADMINISTRATION APPLICATION Page 7

1.2 Language configuration

1.3 Interface administration

CHAPTER 1. INTRODUCTION TO THE ADMINISTRATION APPLICATION Page 8

1.4 Workflow configuration

CHAPTER 1. INTRODUCTION TO THE ADMINISTRATION APPLICATION Page 9

CHAPTER 1. INTRODUCTION TO THE ADMINISTRATION APPLICATION Page 10

See separate chapter about the Dashboards for more information.

See the separate Special report document for more information.

1.6 Reports from the administration application

The administration application provides three reports:

CHAPTER 1. INTRODUCTION TO THE ADMINISTRATION APPLICATION Page 11

See separate chapter about the Reports for more information.

1.7 Message to users

1.8 System table configuration

CHAPTER 1. INTRODUCTION TO THE ADMINISTRATION APPLICATION Page 12

These administration tools are available from the web application:

• User administration + Role administration

CHAPTER 1. INTRODUCTION TO THE ADMINISTRATION APPLICATION Page 13

Information for new administrators

2.1 Find the correct text or code to update

Example screenshot of a case:

CHAPTER 2. INFORMATION FOR NEW ADMINISTRATORS Page 14

2.2 Find a code in a codetable and add a new code

• Find the screen with the name of the codetable.

CHAPTER 2. INFORMATION FOR NEW ADMINISTRATORS Page 15

3.1 What are codetables?

There are several possibilities to limit the content of a codetable.

• Disable a code that should no longer be used.

Example of a list codetable: Body part

CHAPTER 3. CODE ADMINISTRATION Page 17

3.2 Code administration hierarchy

CHAPTER 3. CODE ADMINISTRATION Page 18

3.3 Explanation of ‘Properties’ for codetables

The different codetable can have different properties.

All codetables can be translated.

Mark the code you want to translate and click Properties.

Example: “Head” is called “Hode” in Norwegian.

CHAPTER 3. CODE ADMINISTRATION Page 19

Example: A Unit may be visible only for some user groups.

CHAPTER 3. CODE ADMINISTRATION Page 20

CHAPTER 3. CODE ADMINISTRATION Page 21

CHAPTER 3. CODE ADMINISTRATION Page 22

• How many people were injured ‘offshore’ last year?

3.4.1 Location ‘type’, ‘list’ and ‘connect type/list’

Locations are defined in the Location – list screen.

CHAPTER 3. CODE ADMINISTRATION Page 23