User Management Manual

Users management
User manual
Copyright 2012 Tagetik - All Rights Reserved

Contents
Users management 5
Create a new user 10
Application rights 14
Authorization: role based access 14
What is a role 14
System roles and custom roles 14
Custom role creation 16
Utility 20
Users / Roles relationship 20
Area profiles 24
Create area profile user 25
Create a user belonging to an area 25
Data Rights 27
User rights on entity dimension 29
Restriction type definition 30
Rights on entities 32
Restriction on tasks 41
Restrictions on dimensions 48
Accounts rights 50
Restrictions on custom dimensions 50
Restrictions on categories 50
Restrictions on original scenarios 51
Restrictions on consolidation scenarios 51
Restrictions deployment 51
Restrictions on other dimensions 52
Restrictions on forms 53
ETL Restrictions 54
Closing rules restrictions 54
Restrictions deployment 54
Appendix 55
Block user 55
Password rules 58
Change password 60
Change other user's password 60
Recode user 61
Glossary 65
Users management
Users management
One of the constant of a distributed application and thus of Tagetik is the login win-
dow where a user performs the authentication by entering username and password.
But behind this window there is not only the implementation of the "can I or not
access" mechanism. In an highly structured application various utilities need to be
scheduled, on the base of the type (role) of the user. For example some users can
access only the personnel costs management utilities, without knowing that the same
application manages other utilities. On the other hand, a second group of users may
fully control all the budget utilities and see the personnel cost data in "read only".
Moreover, it is often necessary to manage the data visibility to the various users in a
differed way. For example an entity with several production units may decide to give
visibility to data related to the production unit of the connected user only.
Thus beside the query "can I or not access" the system must schedule more specific
queries such as "which menus can I access? which activities can I perform? and on
which data?" etc...
In order to meet the abovementioned needs, Tagetik provides a user profiling system
that allows to protect sensitive data and to prevent data from being modified by not
licensed users. The profiling activity can be schematized in four steps:
Page 5
Users management
Using an analogy we can say that:

l the authentication corresponds to a badge that allows to access a building;
l the authorization is the access to a particular office of the building (application
database) while the role is the list of tools that can be used in that particular
building;
l the users rights on metadata correspond to deciding which tabs I can consult or
update.
Create a user
A user can be created in two different ways:
l exclusive management in Tagetik. The user is created manually inside the
Repository of Tagetik. In this case we have a local user : the information
required to authenticate the credential of a user performing the login and the
information concerning the access rights are in the Repository of Tagetik;
l management of users in an external system (for example Active Dir-
ectory). At the moment of the login, the required data for the user authen-
tication and profiling are automatically copied in the Repository of Tagetik at
the first access and updated at the following accesses. In this case we have an
external user.
In Tagetik the users are created (manually or via copy utility) in the Repository
database and then copied (via the automatic Refresh Users utility) into each applic-
ation database the user can access. In the users table present in each application
database the user rights will be defined in the data model (namely what the user can
see and what insert / modify).
Thus in Tagetik there is:

l one centralized users table in the Repository database (accessible from Repos-
itory / Users and Roles / Users and Roles / Users / Element) where all users
are stored and the authorizations on the application databases where to work
are defined and so the utilities the user can access;
Page 6
Users management
l one users table in each application database (accessible from Setup & Admin /
Users Rights / Users Rights / Users Rights) where only the users authorized to
access that specific application database are stored and where the user rights
on the data model are defined.
Authentication
It is the process by which Tagetik checks if a user "Can access or not" the applic-
ation.Tagetik has its own user authentication system called "Default authentication"
based on its own Repository with its own users table. But several entities already
have a centralized authentication system of "active directory" type based, for
example, on LDAP technology that contains all information about users, password,
access rights.Tagetik is able to capitalize these repositories so as to perform an
external authentication. Thus external authentication means that when a user gives
his credentials(username and password) for the login, Tagetik accesses his inform-
ation stored in the external active directories in order to authenticate him in real
time.
We may say that the authentication is equal to a badge that allows to access a build-
ing.
Tagetik supports the following external authentication mechanisms:

l Lightweight Directory Access Protocol (LDAP). LDAP is a protocol that
allows to access the directory services and, in particular, allows to interact with
the Windows' Active Directory so as to find the information on the licensed
users. The users related to the LDAP service can access Tagetik by using this
type of authentication and as password the one registered in the LDAP service.
Tagetik allows to specify more than one LDAP configuration so as to perform
the LDAPauthentication also in presence of users related to other domains;
l Java Authentication and Authorization Service (JAAS). JAAS is a group
of libraries and standard utilities employed to implement authentication and
authorization processes independently of the employed platform. All the users
validated from the ldapToActiveDirectory module, defined in the application
server, can access Tagetik by using this type of authentication;
l External Repository (ER). ER is a Tagetik's owner authentication mechanism
that allows to use the Repository of another Tagetik's application so as to not
repeat the users table in both the Repository databases;
l Http Header Customizable (HHC). HHC is a Tagetik's owner authentication
mechanism that allow to validate a user by reading appropriate properties in
the headers of the HTTP request.Thanks to this mechanism the user does not
need to use the username and the password to access Tagetik but he will be
automatically logged by the application;
l Remote Authentication Dial-In User Service (RADIUS). The RADIUS pro-
tocol is used for the remote authentication via specific authentication servers.
The authentication system supported by Tagetik requires username and pass-
Page 7
Users management
word. This authentication system allows to implement a Two Factor Authentic-

ation with the authentication via token;
l Internet X.509 Public Key Infrastructure (IPKI) Client Certificate .
This authentication type can be selected when using a HTTPS connection and
requires a submitted client to authenticate the user. Normally, when a HTTPS
connection is set, only the server provides a certificate. When also the server
requires the client to present a certificate, we have a mutual authentication or
two way SSL authentication
By using the "Default authentication " Tagetik's users authentication system,

inside this mechanism also the SharePoint authentication is automatically managed.
It is a Tagetik's owner PKC-based authentication mechanism that allows the users
logged in the Sharepoint portal to access also Tagetik.
Where to configure the authentication mechanism

The authentication mechanism can be set from Repository / Setup / Setup / Authentic-
ation / Other systems by setting the Sign On Checker information.
Whether the set authentication mechanism is different from the Tagetik's one, the
system requests to configure some parameters. This parameters can be specified:
l via System Properties set in the application Server.In this way the parameters
cannot be modified by the application and the abovementioned management
window displays its value with no way to modify it;
Page 8
Users management
l directly in the abovementioned management window. In this way, whether to

change the value of a parameter is required, it is possible to perform the modi-
fication with no need to restart the application server.
Authorization: role based access

It is the process by which Tagetik checks what a user can do, namely if he is author-
ized to access:
l a determined application database;
l a certain menu or utilities.
Carrying on the former analogy, we can say that the authorization is analogous to
gaining the access to a particular office of the building (application database) while
the role is analogous to the list of tools usable in that specific office.
Set the user rights on metadata

It is the process Tagetik uses to check, for all the utilities the user is authorized to
access, which data he can see and which he can insert / modify.
Carrying on the analogy, after gaining access to a particular office of the building and
being authorized to open a card index, the users rights are analogous to establishing
which index cards the user can consult or update.
Page 9
Create a new user
Create a new user
A user can be created in two different ways:

l exclusive management in Tagetik. The user is created manually inside the
Repository of Tagetik. In this case we have a local user : the information
required to authenticate the credential of a user performing the login and the
information concerning the access rights are in the Repository of Tagetik;
l management of users in an external system (for example Active Dir-
ectory). At the moment of the login, the required data for the user authen-
tication and profiling are automatically copied in the Repository of Tagetik at
the first access and updated at the following accesses. In this case we have an
external user.
In Tagetik the users are created (manually or via copy utility) in the Repository
database and then copied (via the automatic Refresh Users utility) into each applic-
ation database the user can access. In the users table present in each application
database the user rights will be defined in the data model (namely what the user can
see and what insert / modify).
Thus in Tagetik there is:

l one centralized users table in the Repository database (accessible from Repos-
itory / Users and Roles / Users and Roles / Users / Element) where all users
are stored and the authorizations on the application databases where to work
are defined and so the utilities the user can access;
l one users table in each application database (accessible from Setup & Admin /
Users Rights / Users Rights / Users Rights) where only the users authorized to
access that specific application database are stored and where the user rights
on the data model are defined.
In the users table present in the Repository database, each user is identified by:
Page 10
Create a new user
l a code; It is the code the user must insert in the USERNAME field present in
the login opening window to access Tagetik;
l a description;
l an application language, namely language in which the application must be
displayed (menu items, headers, management windows fields names, warning
messages). Tagetik allows to define an Application default language to use
as an alternative when the default language set by the user is not available. To
be more precise, whether the application language is not available, the system
decides in which language to display the application by using the following rule:
it checks if the default application language is available, if not it looks for Eng-
lish and if neither this language is available it displays the application in Italian;
l a table language namely the language in which the system displays the
description of metadata elements;
l a nationality. Tagetik formats numbers and dates on the base of which nation-
ality is assigned to each user;
l a validity start date and a validity end date that, if set, prevent the user
from accessing the application whether the login date is not comprised between
them. For further details see Block user;
l a set of symbols employed by the system to display the indicators
inside the various windows (for example to highlight the unbalanced values
inside the data edit windows, the overrides in the management windows of
some tables or to understand/manage the status of a relationship inside the IC
matching cockpit). If the administrator enables the Use monocolor
symbols option the employed indicators will be black and white symbols
Page 11
Create a new user
whose shape is important, otherwise they will be symbols with the same shape
whose colour is important;
l a password rule.
The system, while creating a new user, assigns as default value to the application
language, application default language, table language and country information the
value set in the Repository configuration.
Moreover for each user it is possible to:

l set additional information such as email address, phone number and notes;
l block temporarily the access to the application enabling the Blocked Tem-
porarily option or using the Actions ( )/ Remove users / Block/Unblock user

window menu. For further details see Block user;
l override the password change via the Actions ( )/ Change Password win-
dow menu.
l modify its password rule via the Actions ( )/ Change password rule window
menu.
Utility
Preferences management
At single window level the user can:

l modify the window's width and height. By default the windows open so as
to fill up the full work area (area edged between the menu bar and the left side-
bar). The window's size can be modified to your liking. For this purpose it is
necessary to:
o unhook the window from the work area it fills up simply by dragging the
title bar;
o position the mouse cursor on an edge or a corner of the window, the cursor
turns into a double-headed arrow. By keeping clicked the button of the
mouse while the cursor is double-head shaped and by dragging the edge or
the corner of the window, the user can modify one size (edge) or two sizes
(corner) of the window.
l decide which columns must be displayed and in which order. This util-
ity affects only the grid part of the window;
l decide if determined columns must remain blocked and thus always vis-
ible when the content of the window is scrolled. This utility affects only the
grid part of the window;
l In presence of grid-detail windows, decide the proportion of the grid com-
pared to the detail . In order to modify the grid's height the user must use
the button present under the separation line between the grid and the detail.
Page 12
Create a new user
Once the user has performed such modifications, the new settings can be saved by
using the Save preferences button present in the buttons bar of the window so
as that, at the following opening, Tagetik displays it in compliance with the new set-
tings. The user can change the saved settings whenever he wants or reset the default
settings by using again the button . Indeed Tagetik, if preferences already exist for
a determined window, asks if the saved preferences must be overwritten or deleted
and thus the default settings re-enabled.
The preferences management is then performed for each user / window but Tagetik
provides also two utilities that allow to
l display for each user the saved preferences and thus to have a global vision on
all windows. This utility can be accessed from Repository / Users and Roles /
Users and Roles / Users / Element / Actions / Manage preferences;
l delete some preferences from more windows at the same time. This utility can
be accessed from Repository / Users and Roles / Users and Roles / Users / Ele-
ment / Actions / Manage preferences;
l copy the preferences set on a determined window from a user to another. This
utility can be accessed from Repository / Users and Roles / Users and Roles /
Users / Element / Actions / Copy preferences;
Page 13
Application rights
Application rights
Authorization: role based access

As previously stated, the authorization is the process Tagetik uses to check if a user
is authorized to access:
l a determined application database or the Repository database;
l a determined menu or utility.
The parameterization of such process is based on the concept of role and requires the
system administrator to specify:
l the relationship between user / Repository database and user / one or more
application databases, so as to show to the system the applications the user
can access;
l the relationship for each user / database pair with the role, so as to show to the
system the list of the activities the user can perform (set of visible menus).
What is a role
The role defines the activities a user can perform in Tagetik. A role is described by a
list of functions, that is a list of simple operations of the application that a user can
choose and perform. Typically the functions are:
l windows / tables managements
l data processing
l report
and in the most of cases a function corresponds to a menu key or to a window menu.
The Role defines if the User can use each function fully, only in display mode (as far
as tables are concerned) or if he cannot use it at all.
The functions present in a X role are only those available to the user who accesses a
database by using the X role.
System roles and custom roles

In Tagetik there are two types of role:
l System roles. These roles are preset and essentially cover the most of advant-
ages to assign to the various users. The users cannot modify their definition or
delete them. The system roles are identified by a code beginning with the char-
acter $and can be accessed from Repository / Users and Roles / Users and
Roles / Roles / System roles table . The system roles scheduled by Tagetik are:
System role Actions
$ALL A user provided with this role can access any util-
Page 14
Application rights
System role Actions
ity
$ADMINISTRATOR A user with this role gets advantages as unique

administrator of the application database and can:
l define the basic and user rights tables
l parameterize the rules (Cash Flow Planning,
Allocation and Closing, consolidation, ETL);
l configure the data entry and the reporting
by managing the data entry / output forms
layout and the reporting schemes;
l parameterize the database process;
l perform operations on data preliminary to
data entry by other users as changes inser-
tions and tax rates
A user with this role CANNOT perform the data
entry of original data
$AUDIT A user provided with this role can visualize all data
and all the tables but he cannot modify them
$CONSOLIDATOR A user provided with this role has the advantages

of a Consolidator and can:
l perform data entries related to the con-
solidation: consolidation adjustments, con-
solidation data processing (proportional
calculation, minorities generation, con-
version, GPN, equity entities treatment);
l perform the Legal Structures data entry;
l manage the intercompanies;
l monitor the single contributor's activity.
$SYSADMIN A user with this role has advantages as system

administrator and operates only on the Repos-
itory. He can:
l create custom roles;
l create users and define their roles;
l manage the users visibility on the applic-
ation databases;
l manage the data processing's run mode and
their scheduling;
l manage the database import and export;
l manage the logs
Page 15
Application rights
System role Actions
$USER A user provided with this role has the advantages

of a Contributor. He can:
l perform the amounts and preconsolidation
adjustments data entry;
l perform the data entry from form;
l perform the IC entries data entry;
l perform the ICentries matching;
l perform the data processing of a single
entity;
l perform the diagnostic per each entity;
l submit data.
All these activities are limited to the entities
whose user has rights
$ANALYTICS A user with this role can see the reports published
on Tagetik Analytics Web portal according to his
rights but he cannot access the web side of the
application
l Custom role. These roles meet the need of defining specific groups of activ-
ities different from those scheduled by the system roles.
Custom role creation

The custom roles table can be accessed from Repository / Users and Roles / Users
and Roles / Roles / Roles table.
Each custom role is identified by:

l a code;
l a description;
Page 16
Application rights
l a list of functions, namely a list of simple operations of the application a

user can perform, chosen among all the operations of the application.
The definition of the functions that compose a certain custom role can be performed:
l from scratch. In this case the administrator inserts one by one the functions
or the modules (functions collection) and indicates for each one if it is enabled,
disabled or enabled in read only. It is possible to add or delete single functions
from the modules. The management windows of the functions that constitute a
role can be accessed from Repository / Users and Roles / Roles / Roles table /
Actions ( )/ Details / Enabled functions
l starting from another role called "reference roles. In this case the func-
tions the systems considers related to the X role are gained:
o by summing all functions of the reference role;
o by applying overrides, in addition or subtraction, directly related to the
role.
Defining a role as sum of other roles (namely by using reference roles) is par-
ticularly useful when overrides are required; otherwise, the "sum" of the role's
functions can be gained by relating more roles to the single users, without defin-
ing further "sum" roles. The reference roles management windows can be
accessed from Repository / Users and Roles / Users and Roles / Roles / roles
table / Actions ( )/ Details / Reference roles (in this case the reference roles
can be defined only for the selected role) or from Repository / Users and Roles
/ Users and Roles / Roles / Users/Ref. Roles relationships / Reference roles
Page 17
Application rights
In both cases, during the saving, the system deploys the inserted data so as to gen-
erate a deployed table where, for each role, it specifies:
l the functions related to the role;
l for each function, if it is available to the user or if the user can only view the
table but not modify it.
Any modification applied to the role can be applied automatically to all custom
roles having this role as reference role just by deploying the roles.
Examples
Example 1: Let us assume we want to define a USER_EXCHANGE_RATE custom role

for which all the activities of the $USER system role and the exchanges management
are enabled. The steps to follow are:
1- In the custom roles table, create a record having "USER_EXCHANGE_RAT" as code
and "User + Exchange rate management" as description;
2 - For the USER_EXCHANGE_RAT indicare role, specify as reference role the $USER
role;
Page 18
Application rights
3 - For the role, apply an override by enabling also the "0000227 - Administration -
Basic Admin - Data - Exchange Rates" function.
Example 2 : Let us assume we want to define "from scratch" a custom role that
allows us to access in read only both the master data tables and the data tables. The
steps to follow are:
1 - In the custom roles table, create a record having "USER_VIEW" as role and "User
view-only" as description;
2 - Assuming that FOUND_PARAM is the module containing all the functions related to
the tables management and GENERIC_DATAENTRY the module containing all the func-
tions related to the generic data entry (amounts, preconsolidation adjustments...),
define the functions to enable for the role as follows:
Page 19
Application rights
Example 3: Let us assume we want to create an user being at the same time admin-
istrator and consolidator but not contributor. In this case we can act in two ways:
l create a custom role having as reference roles the two system roles
$ADMINISTRATOR and $CONSOLIDATOR;
l not use the reference roles but just, during the relationship step of the user to
the application database on which it must be enabled, relate it to the two sys-
tem roles $ADMINISTRATOR and $CONSOLIDATOR . For further details about
the user / role / database relationship see Users / Roles relationship.
Utility
Copy
The definition of the functions related to a role can be performed manually or by copy-
ing it from another existing role and then performing the needed modifications. This
utility can be accessed from Repository / Users and Roles / Users and Roles / Roles /
Roles table / Actions ( )/ Copy enabled functions from and allows to copy the func-
tions definition from a custom role to another.
Users / Roles relationship

After defining the roles, the administrator must, for each user, define the list of
application databases where he can work so as to specify the applications the user
Page 20
Application rights
can access and at the same time, for each database, relate a role so as to specify the
list of activities the user can perform (set of visible menus).
If we look at the image above we notice that the User1 :

l cannot access the DB3 database since there is no relationship with such data-
base;
l on the DB1 database he can perform all the activities given by the sum of the
activities enabled for the Role X and the activities for the Role Y;
l on the DB2 database he can perform all the activities enabled for the role X.
This relationship can be performed directly, namely by specifying an application data-

base / user / role or by using the reference roles:
l Direct relationship. For each application database, the user is related
to a role or a list of roles. In this case the list of activities a user can per-
form is represented by the sum of the activities belonging to all the roles
related to the user for that database. This type of definition can be accessed
from Repository / Users and Roles / Users and Roles / users/roles relationships
or directly from the users table via the Repository / Users and Roles / Users
and Roles / Users / Element / Actions ( )/ Details / users/roles relationships

window menu.
Page 21
Application rights
For each user / database specify:

o a role. The role with which accessing a database is defined in this window
only if, for the current database, only one role was assigned to the user.
Otherwise it is necessary to enable the Multi-role option and then define
the list of roles from the Details window menu;
o if the user cannot access the database at the moment. By default a new
user cannot access any database, namely the Blocked temporarily
option is enabled. This is due to the fact that otherwise the user may
access the application and perform all what is enabled for his role before
the administrator has defined possible restrictions in visibility and inser-
tion/submission on data dimensions. For further details see Block user;
o a validity start date and a validity end date that, if set, allow to block
the visibility of the current database whether the login date is not com-
prised between them. We remind you that this information can be set also
directly in the users table but, in this case, it is valid for all the application
databases the user can access;
o if, during the synchronization step of the application database's users
tables with the Repository's users tables, the user must be inserted with no
restrictions on the dimensions (Unrestricted), restricted on all dimensions
or restricted only on the entity dimension, category and consolidation scen-
arios (Restricted (default)).
l Relate using reference roles. A list of reference users is related to
the user. In this case the activities a user can perform are represented by the
sum of the activities the user can access for the roles assignment (as men-
tioned above), and all the functions the set of reference users can access in
that application database. Typically the reference users are employed when
some users must have the same rights as others.
Thus a reference user is a user that can be given a reference by others in
order to inherit the roles and the databases to access. A reference user can be
a fictitious user or a real user. The reference users can be defined from the
users table accessible from Repository / Users and Roles / Users and Roles /
Users / Element by enabling the Reference user for other users option (the
red highlighted field in the following image).
Page 22
Application rights
Similarly each user that must inherit the roles from one or more reference
users will have the Inherit roles from Reference user option enabled in the
table (blue highlighted field in the previous image).
The definition of the reference users related to a user can be accessed from
Repository / Users and Roles / Users and Roles / Users / Element / Actions (
)/ Details / Reference Users.
A user can be a reference user:

l only for the roles;
l only for rights on data;
l for the both.
For example, if we have 10 users USER1,..., USER10 all having the $USER role but on
different entities, we will create:
l the USER1 user having:
o on the users table of the Repository database the "Reference user for other
users" option enabled, namely it will be a reference user for the roles;
o in the users table of the application database, the " Reference user for
other users" option disabled, namely it will not be a reference user for the
restrictions on data;
o$USER role in the application database
l the USER2, ..., USER10 users with the "Inherit roles from Reference user "
option enabled and, as reference user for the roles, the USER1 user
l A user can access a database if a role has been directly assigned to him in such
database or if at least one of his reference users has a role in such database.
l A user can access several databases at the same time with different roles.
Page 23
Application rights
Examples
Example 1: Let us assume to have a user USER1 and three application databases
TEST1, TEST2, PRODUCTION. While defining the user / database / role relationships
we can define
USER1 TEST1 ROLE X
USER1 TEST2 ROLE Y
In this case the user USER1 can work in the TEST1 and TEST2 databases but not in
PRODUCTION since no row relates the user to the PRODUCTION database. Moreover,
in TEST1 the user can perform all the activities defined for the role X while in TEST2
all the activities defined for the role Y.
Example 2: Let us assume we have defined "piecemeal" roles, namely several roles
each one enabling a limited group of activities: in this case, in order to enable the
user to all the activities, we can relate a list of roles in a certain database so as to
have the single role
USER 1/TEST1/ROLEK
USER 1/TEST1/ROLE L
USER1/TEST1/ROLEM
Example 3: Let us assume we have 10 users USER1, ..., USER10 that must perform
the same activities in the PRODUCTION database. In this case we can create a USER1
reference user, define his role in the PRODUCTION database and let the other 9 users
inherit the roles from USER1.
Area profiles
Tagetik allows the system administrator to delegate other peripheral administrators
to manage the authorizations of a users group (area).
This is realized introducing the concept of area profile.
An area profile is a fictitious user that, in terms of roles and restrictions on data, rep-
resents the limit of what the peripheral administrator is allowed to do.
The users belonging to a determined area and thus managed by the same area profile
cannot perform other activities than those assigned to the area profile; namely, they
cannot do more than the area profile can.
Page 24
Application rights
If a user is related to an area profile in the Repository, then for each application data-
base the list of functions assigned to him can never exceed the activities related to
the area profile for that application database.
If a user is related to an area profile in the application database, then in that applic-
ation database the elements of the single dimensions he can access cannot exceed,
dimension after dimension, the elements the area profile can access.
Create area profile user

The administrator can create an area profile user in the users table (Repository /
Users and Roles / Users and Roles / Users / Elements ) by enabling the Area
profile option. The administrator will assign to this user a role that allows him to
manage the users.
Create a user belonging to an area

The administrator or the area profile user can create a user and assign to him a
determined area in the users table (Repository / Users and Roles / Users and Roles /
Users / Element) by enabling the Inherit Area profile from another user option
and setting the area field with the area profile user's code.
Page 25
Application rights
Page 26
Data Rights
Data Rights
The definition of the user's rights on data is the process by which Tagetik checks, for
all the utilities a user is allowed to access in an application database, whish data he
can see (visibility) and which ones he can insert / modify (editability). In this way the
system can have both the group of data visible to the user and the group of data the
user can edit (the two groups can be different from each other).
A distributed application like Tagetik generally involves few administrators and many
contributor users. That is why the request to limit the group of elements in which data
can be inserted/modified is very common. For Example, the contributor user A may
see and edit only data of the entity A00 while the contributor user B may see and edit
only data of the entity B00. Such rights can be defined by specifying which elements
of a dimension must be included into the editable elements set of a user.
In Tagetik the user rights on data are:

l rights on entity dimension. The entities (entities or nodes) on which the
user can perform some activities are indicated and the activities specified. The
activities the user can perform on the entities: are:
o edit entity's data;
o submit the entity;
The activities the user can perform on the nodes are:

o edit the node's consolidation entries;
o submit the node;
It is important to notice that:

o any activity the user can perform on
n an entity this implies automatically the entity's visibility;
n a node this implies automatically the visibility of the node and of all the
underlying entities.
o the entities the user can only display must be explicitly specified
l rights on accounts, original scenarios, categories, custom dimension.

Such rights operate both on the editability and on the visibility. If a user can
manage one element of such dimensions then he can also visualize it. The ele-
ments of such dimensions the user can only display must be explicitly spe-
cified. For example if a user is allowed to access a subset M (e.g. C1, C2)
among the N existing categories (e.g. C1, C2, C3 and C4), then the user will be
able to manage and see data characterized by the M categories but he will not
be able to see data characterized by the remaining N-M categories (C3 and C4).
l rights on consolidation scenarios. These rights operate both on the vis-

ibility and on the possibility of processing a consolidation scenario. If a user
Page 27
Data Rights
can process a consolidation scenario then he can automatically visualize it. The
consolidation scenarios the user can only display must be explicitly specified
l rights on WF Model. These rights operate on the possibility of processing or

not a task inside a workflow model
l rights on attributes and Work order type of the Expense Management

module. Such rights operate both on the editability and on the visibility. If a
user can manage one element of such dimensions then he can also visualize it.
The elements of such dimensions the user can only display must be explicitly
specified.
l rights on forms and ETL routines (automatic loading procedures), closing

rules, CDM documents and data processing of the Production Control
module. These are "secondary" rights that do not limit visible data but only the
possibility that the user employs a form or an ETL routine or a closing rule or a
CDM document or a data processing of the Production Control module
The definition of the user rights can be performed:

l defining the elements of the single dimensions the user can access;
l relating to the user a list of reference users. In this case the elements of the
single dimensions the user can access are represented, dimension by dimen-
sion, by the elements the user can access according to what is directly assigned
him, and all the elements assigned to the group of his reference users. The ref-
erence users are employed in two typical situations:
o when some users must have the same rights as others;
o when we want to use "visibility models", to use freely for the users pro-
filing. For example when there is a users class that must have a determ-
ined right on categories and on scenarios, it is possible to create a
reference user (in this case a fictitious one) that on scenarios and cat-
egories has the required rights and on the other dimensions has no vis-
ibility.
Thus a reference user is a user that can be given a reference by others so as to
inherit rights on data. A reference user can be a fictitious user or a real user.
The definition of the reference users can be performed in the users table of the
application database accessible from Setup & Admin / User rights / User rights
enabling the Reference users for other users option (field highlighted in
red in the following image).
Page 28
Data Rights
Similarly, each users that must inherit rights on data from one or more ref-
erence users will have the Inherit restrictions from the Reference user
option enabled in his table (field highlighted in blue in the previous image).
The definition of the reference users related to a user can be accessed from
Setup & Admin / User rights/ User rights / User rights / Actions ( )/ Details /
Reference Users.
User rights on entity dimension

Restriction:
l on the entities allows the administrator to define for each user the entities /
nodes on which data can be displayed and/or data can be inserted and sub-
mitted;
l on tasks allows the user to perform, for the entities on which he has rights,
only the activities "tasks" which are related to him (for example the data entry
in a given form, the run of a given data processing etc...).
The permissions on the entity dimension are defined by organizational hierarchy
since the same user may have several permissions for several application processes.
For instance the user might have, in the consolidation process, in editability the entit-
ies A and B but not the entity C, while in the budget process he might have in visibility
the entity B, in editability the entity C and no permission on the entity A. This result is
obtained by using two different organizational hierarchies: one for the consolidation
process and one for the budget process.
Page 29
Data Rights
The permissions on the entity dimension are defined according to the rule that each
editable/submittable entity/node is automatically visible as well. Thus:
l whichever activity the user can perform on an entity, the visibility is not auto-
matically implied .
l whichever activity the user can perform on a node, the visibility of the node
and of all the entities below is automatically implied .
If needed, the entities which the user has in visibility only have to be explicitly spe-
cified.
For example for the user USER1 we can have:
Editability rights = entity A, B and C
Visibility rights = entity A, B, C (inherited from editability rights) and D (visibility
only)
In Tagetik by default a new user is "restricted" on the entities and not restricted
on the tasks. This means that until the entities he can access are not inserted manu-
ally, he has not visibility on any entity. But after defining the entities he can run,
unless there is a specific restriction, all tasks of the various Workflow Models.
Restriction type definition

For each user who is allowed to work on a determined application database it is neces-
sary to specify if on the entity dimension and on the tasks defined within each work-
flow model, the user has all rights on all the existing elements or if it is necessary to
specify manually the editable / visible elements. For this purpose it is necessary to
open the users table of the application database accessible from Setup&Admin / User
rights / User rights / User rights and position on the Restrictions on dimensions
tab.
Page 30
Data Rights
and set the Entity and task attribute with:

l Unrestricted in insertion, submission and display. The user can edit, sub-
mit and display data of all entities;
l Restricted in insertion and submission, but not restricted in display.
In this case the user has rights only on the elements explicitly declared as edit-
able / visible. The definition of such elements is performed by a dedicated man-
agement window accessible from the window menu Actions ( ) / Restrictions

Entity and task
l By area profile. If the user belongs to an area profile, he inherits in data
entry and in display all the entities related to that profile;
l Restricted in Insertion, Submission or Display by Area profile. A user
who inherits the area profile can be further limited. In this case the system
intersects the entities of the area profile and the entities defined in the Actions
( ) / Restrictions entity and task window;

l Limited. The user is limited both in data entry/submission and in visibility only
to the entities defined in the Actions( ) / Restrictions entity and task window
Page 31
Data Rights
Rights on entities
The management of rights on the entity dimension, when the restriction type is
"Restricted...", can be accessed from Setup&Admin / User rights / User rights / User
rights/ Actions ( defined in the Actions( ) / Restrictions entity and task window) /
Restrictions Entity and Task and then selecting the Entity section.
The description of the management of rights on entities is performed when the restric-
tion type is "Limited" because in the other cases the information to manage is just a
subset.
The window is divided into five different tabs:

1 - Entity rights
in which rights on the single entities are defined. The entities are selected, at the left
side of the window, form one of the various organizational hierarchies and then
moved to the definition side to the right.
The definition can be:
l analytic, by single entity (each record represents one single entity);
l synthetic, by nodes of an organizational hierarchy (each record represents the
group of entities which belong to the node). In this case during the deployment
the system deploys the node and inserts in the Deployed - Entity tab all the
entities related to the node.
Whether the definition is analytical or synthetic, for each record it is necessary to spe-
cify explicitly:
l if the data entry is enabled (Insert data). If this option is not enabled, the
user can perform any activity on that entity but the data entry and the con-
tributor data processings (example: to open guide lines tasks, to download sup-
port documentation, etc...);
l if the user can run:
o all operational tasks (Run operational tasks - All), namely all tasks
which are not approval/submission;
Page 32
Data Rights
o only one limited set of operational tasks that can be selected within a:
n Generic list (Run operational tasks - Generic list). In this case the
definition is performed in the Generic list Task tab of the Restriction

Entity and Task definition window and is valid for the entities having the
"generic list" option enabled;
n Specific list (Run operational tasks - Specific list). In this case the
definition is performed from the row menu (selecting the record via
double click or from the Actions/ Details) of the selected record. This
option allows to limit the user on the tasks to run in relation to the
entity;
n only a limited set of operational tasks (Run operational tasks - List).
In this case the definition is performed in the Tasks section of the defin-
ition window of the restrictions Entity and Task;
o no operational tasks (Run operational tasks - None).
o all submission/approval tasks (Run submission tasks - All)
o only a limited set of submission/approval tasks that can be selected within
a:
n Generic list (Run Submission tasks - Generic list). In this case the
Entity and Task definition window and is valid fr the entities having the
n Specific list (Run Submission tasks - Specific list). In this case the
definition is performed form the row menu (selecting the record via
entity
o no submission / approval task (Run submission tasks - None).
2 - Contributor nodes rights

in which restrictions on contributor nodes are defined (for example sub-
mission/approval of a given node).The definition is performed by selecting from an
organizational hierarchy the nodes which, in the application process, have a type dif-
ferent from None, namely they are not nodes created only to design the organ-
izational structure but they correspond to a manager who has to check the end of the
data entry and their approval / submission. These nodes are labeled by a green
folder. For each node it is necessary to specify:
l if the submission rights have to be applied:
o to the current node
o to the node and all the child nodes
o to the last level children
o to the children nodes of a given level (fro 1 to 9)
o all the submission/approval tasks (Run submission tasks - All);
a:
Page 33
Data Rights
Entity and Task definition window and is valid for the nodes having the
option allows to limit the user on the tasks to run in relation to the node
o no submission/approval task (Run submission tasks - None).
3 - Consolidator nodes rights

in which the restrictions on consolidation nodes are defined (for example on IC elim-
ination data processing or insertion of consolidation adjustments which are related to
the elements under the examined node). The definition is performed by selecting
from a organizational hierarchy the nodes which in the consolidation process have to
be consolidated. These nodes ale labeled by a green folder. For each node it is neces-
sary to specify:
l if the submission rights have to be applied:
o to the current node
o to the node and all the child nodes
o to the last level children
o to the children nodes of a given level (from 1 to 9)
l if the data entry of the consolidation adjustments is enabled (Insert data).
l if the user can run
o all operational tasks (Run operational tasks - All);
o only a limited set of operational tasks that can be selected within a:

node;
o no operational task (Run operational tasks - None)
l if the user can run
o all submission/approval tasks (Run submission tasks - All)
a:
Page 34
Data Rights
option allows to limit the user on the tasks to run in relation to the node
o no submission tasks (Run submission task - None)
4 - Visibility
in which are defined the entities which have not been specified in the "Contributor ele-
ments rights" tab of which we only want to display data. By default each entity / edit-
able / submittable node is automatically also visible. Thus:
l whichever activity the user can perform on an entity, its visibility is auto-
matically implied.
l whichever activity the user can perform on a node, the node's visibility and of
all the entities below is automatically implied
5 - Generic task list . See Restriction on tasks.
After completing the Entity rights definition, it is necessary to run the deployment
(via the button) in order to generate the detail tables the system uses when applying
the user rights. The result of the deployment is displayed in the "Deployed data" area
of the Restriction Entity and Task definition window.
This window is divided in seven tabs:

l Entity that shows the result of the entity rights deployment namely the
detailed list of the editable entities;
l Nodes that shows the result of the entity rights deployment namely the
detailed list of editable and/or visible nodes (contribution and consolidation);
l Visibility that shows the detailed list of visible entities;
l Generic task list that shows the result of the generic task list deployment
namely the detailed list of the approval / submission tasks that can be run by
the user
l Entity specific task list that shows the result of the specific task list deploy-
ment namely the detailed list of approval / submission tasks that can be run by
the user for a specific entity
Page 35
Data Rights
l Contributor nodes specific task list that shows the result of the specific
task list deployment namely the detailed list of approval / submission tasks
that can be run by the user for a specific contributor node
l Consolidator nodes specific task list that shows the result of the specific
task list deployment namely the detailed list of approval / submission tasks
that can be run by the user for a specific consolidator node
EXAMPLES
Let us assume that we have the following organizational hierarchy
Example 1: User with editability and visibility rights on all entities of the node B00
It is necessary to set the entity restriction type to "LIMITED", access the Restriction
Entity and Task definition window (via double click or from the Actions ( ) / Restric-
tion Entity and Task menu) and in the "Contributor elements rights" tab:
l select the node BOO - Subholding B on the left side of the window;
l enable the Insert data option in order to allow the user to collect and see data
on the four entities;
l specify that the user can run all the operational tasks setting the Run oper-
ational tasksoption with All;
l specify that the user can run the submission tasks setting Run submission
tasks with All;
l click on the button . The system inserts a record in the right side of the win-
dow using the "Add" action. This means that the user has the editability and vis-
ibility rights on all entities related to the node.
Page 36
Data Rights
Accessing the "Visibility" tab is not needed because in this example no visible entities
have to be added in addition to the entities to edit / submit on the first tab.
After saving the definition and running the "User rights - Entity rights" deployment,
the system displays in the "Entity" tab of the "Deployed data" area the list of the four
entities available to the user.
In the "Visibility" tab the system shows the entities of the node E B00 with restriction
type to edit/submit that means that the deployment generated these entities in vis-
ibility since they (or the related node) have been defined as to edit/submit entities in
the first tab "Entity rights" of the "Definition" area. This is due to the above men-
tioned logic according to which each entity / node to edit / submit is automatically vis-
ible as well.
Page 37
Data Rights
Example 2: Data entry exception management - User with editability and visibility
rights on all entities of the node B00 except entity B03. It is necessary to set the
entity restriction type to LIMITED and access the Restriction Entity and Task defin-
ition window (via double click or from the Actions ( ) / Restriction Entity and Task
menu). In order to set this restriction it is possible to define manually the list of "edit-
able" entities or working by exception as shown below:
l select the node BOO - Subholding B on the left side of the window;
l enable the Insert data option in order to allow the user to collect and see data
on the four entities;
l specify that the user can run all operational tasks setting the Run operational
tasksoption with All;
l specify that the user can run the submission tasks setting Run submission
tasks with All;;
dow via "Add" action. This means that the user has the editability and visibility
rights on all entities related to the node;
l select the Entity B03 on the left side of the window;
l click on the button . The system inserts a record on the right side of the win-
dow by "Delete" action. This means that the user has no rights on the entity
B03.
Page 38
Data Rights
,
the system displays in the "Entity" and "Visibility" tabs of the "Deployed data" area,
the list of three entities available to the user. This list does not include the entity B03
and this means that the user cannot see, insert or modify data of this entity.
Please pay attention to the order in which the records are inserted because the
system processes them following the order in which they are displayed
Page 39
Data Rights
The records sorting can be modified as follows:

l using the buttons between the selection area and the definition area. In par-
ticular, the button moves the selected record one position up and the button
moves it one position down;
l using the drag & drop
Example 3: Management of visibility different from editability. User with editability

and visibility rights on all entities of the node B00 except entity B03. It is necessary
to set the entity restriction type to LIMITED, access the Restriction Entity and Task
definition window (via double click or from the Actions ( ) / Restriction Entity and
Task menu) and in the "Entity rights" tab it is necessary to set the restriction as
defined in the example 2. Moreover, in this case it is necessary to access the "Vis-
ibility" tab and insert the Entity B03 that must be visible.
After saving the definition and the "User rights - Entity rights" deployment, the sys-
tem displays in the "Entity" and "Visibility" tabs of the "Deployed data" area, the list
of four entities available to the user. In this list, the first three entities have the
restriction To edit / submit and the entity B03 is visible only and has the Right type
field set to Visible only.
Example 4: Visibility inherited from the nodes restrictions: Submitter user of the
consolidation node A00.
A user that can submit on a consolidation or approval node, on a contributor node
(without read rights on the elements) has implicitly the visibility on all the node's ele-
ments.
Page 40
Data Rights
In order to limit the user in submission on the consolidation node it is necessary to

access the "Consolidator node rights" tab and:
l select from the left pane the consolidation node A00 to submit;
l Set the Node typeoption with "The current node";
l specify that the user can run all the operational tasks setting the Run oper-
ational tasks option with All;
l specify that the user can run all the submission tasks setting Run submission
task withAll;
l click the button . The system inserts a record in the right side of the window
via "Add" Action
the system displays the selected record in the "Nodes" tab of the "Deployed data"
area and in the "Visibility" tab all the entities belonging to the selected node with the
Right Type field set to "Visible inherited from to edit/submit".
Restriction on tasks
The task rights management is accessible from Setup & Admin / User Rights /User
Rights / Restriction Entity and Task selecting the "Generic task list" tab and it has to
be set if in the "Definition" area (see above) the "Run operational/submission tasks"
option has been set with "Generic list" in the various tabs
Page 41
Data Rights
The definition of the runnable tasks can be managed in two alternative ways:
l working on the tasks. For each available Workflow Model it is possible to
select the whole step or the whole task list or the single task the user can
access. For example, if a given user can perform various operations in the vari-
ous steps then it is possible to select within each step the tasks the user can
manage. For instance, in a Budget process a key account manager can insert
the quantity he expects to sell when collecting the information related to the
revenues and insert the costs of the department for which he is responsible
(example, access the Opex form) in the operational costs collection step;
l working by label. This modality is useful when the user is authorized to per-
form always the same operations in the various steps: for example, giving the
first approval or running the preliminary data processing of each step. In this
case, working by label is easier. Indeed the various tasks throughout the vari-
ous steps can be grouped by label. So assigning to each preliminary task (of
the various steps) the usual label "A", it is possible to assign only one restric-
tion row for that given user specifying that: the user is restricted on the label
"A" and he can run all the tasks related to this label.
The label that group the various tasks is defined and related to the various tasks
in each flow chart within the workflow model from the menu Setup & Admin / Work-
flow model / Workflow model / Action / Definition / WF by label.
Page 42
Data Rights
When task restriction has to be diversified by entity / node, in the various tabs it
is necessary to set the "Run operational / submission tasks" option with "Specific list"
and then define the various tasks by double clicking on the record. The restriction
definition window is like the one described for the "Generic list".
EXAMPLES
Example 1: User rights in a budget process.
Let us assume that the user has to run all the operational tasks of the Revenues Col-
lection step and of the Opex insertion task in the Opex/Capex step on all the entities
except the ones of North America where only the Global Assumption insertion task
(10GLAS) is enabled in the Payroll step.
This requires to set the entity right type to "LIMITED" and access the "Restriction
Entity and Task" window (via double-click or from the menu Actions ( ) / Restric-
tion Entity and Task). Then in the Entity Rights tab:
l select the root of the Regional View organizational hierarchy on the left side of
the window;
l enable theInsert data option;
l specify that the user must be limited on the operational tasks to run setting the
Run operational tasks option with Generic list;
l specify that the user must be limited on the submission tasks to run setting the
Run submission tasksoption with Generic list;
l click on the button . The system inserts a record in the rights side of the win-
dow using the "Add" action;
l select the node C00-North America of the organizational hierarchy in the left
side of the window;
l enable the Insert dataoption;
l specify that for that specific node, the runnable operational tasks are not those
in the generic task list setting the Run operational tasks option with Spe-
cific list;
l specify that for that specific node the submission nodes are not those in the gen-
eric task list setting the Run submission taskwithSpecific list;
dow using the "Add" action
Page 43
Data Rights
Once saved, access the "Generic task list" tab and:

l select for the budget process BDG - Budget & Planning the whole step 10_RV -
Revenue-Cogs Plan;
l select for the budget process BDG - Budget & Planning the task 30OP - Opex of
the OPX - Opex Capex della fase 40_OP - Opex / Capex Plan task flowchart ;
l click the button . The system inserts a record in the right side of the window
using the "Add" action
Now double click on the row related to North America in the "Entity Rights" tab to
define the specific task list and in the displayed window:
Page 44
Data Rights
l select for the budget process BDG - Budget & Planning the task 10GLAS -
Payroll Global Assumptions of the task flowchart PPU - Payroll Planning USA of
the step 20_PP - Payroll Plan;
After running the deployment ( ) the system displays in the Deployed data area:
l in the "Generic task list" tab the result of the generic task list deployment
namely the list of approval / submission task that can be run by the user;
l in the "Entity specific task list" the result of the specific task list deployment
namely the detailed list of the approval / submission tasks that can be run by
the user for all the entities related to the node C00-North America.
Page 45
Data Rights
Example 2: User rights on a given label "3" that groups all the data processing tasks
in the various steps.
Let us assume that within the workflow model related to the budget process BDG the
label 3 has been related to the task 30GRLS - Gross Sale.
In order to define the above mentioned restriction it is necessary to set the entity
right type to "LIMITED" and then access the Restriction Entity and Task window (via
double click or from the menu Actions ( ) / Restriction Entity and Task). Then in the
Entity rights tab:
l select the root of the Regional View organizational hierarchy on the left side of
the window;
l enable the Insert dataoption;
l specify that the user must be limited on the operational tasks to run setting the
Run operational tasks option with Generic list;
l specify that the user must be limited on the submission tasks to run setting the
Run submission tasksoption with Generic list;
Page 46
Data Rights
Once saved, access the "Generic task list" tab and in the "Label" tab:
l select for the budget process BDG - Budget & Planning the label 3
l click on the button . The system inserts a record in the sight side of the win-
Page 47
Data Rights
After saving and running the deployment ( ), the system displays in the Deployed
data area in the "Generic task list" tab all the runnable tasks with the label specified
during the definition step.
Restrictions on dimensions
These restrictions are applied on the elements of the following dimensions:
l account;
l Category;
l Custom dimensions;
l original scenario;
l Consolidation scenario
they act both on the editability (as far as the consolidation scenario is concerned, by
the word editability we mean the possibility of processing the scenario) and on the vis-
ibility. If a user can manage one element of such dimensions then he can auto-
matically also visualize it.
The elements of these dimensions that the user can only display must be explicitly
specified.
For example if a user is allowed to access a subset M (e.g. C1, C2) among the N exist-
ing categories (e.g. C1, C2, C3 and C4), then the user will be able to manage and see
data characterized by the M categories but he will not be able to see data char-
acterized by the remaining N-M categories (C3 and C4).
By default, in Tagetik any new user has all rights for the existing elements. It is pos-
sible to limit the editability and/or visibility by specifying manually the editable
and/or visible elements.
The only two exceptions are given by:
l the category for which it is assumed that each new user is a contributor,
namely that he has rights only for the contributor's categories;
l the consolidation scenario for which each new user as no rights for any con-
solidation scenario by default.
Page 48
Data Rights

For each user allowed to work on a determined application database it is necessary to
specify for each of the above mentioned dimensions if the user has all rights for all
the existing elements or to specify manually the editable / visible elements. For this
purpose it is necessary to open the users table of the application database accessible
from Setup & Admin / User rights / User rights / User rights, then position on the
Restrictions on dimensions tab
and set for each of these dimensions the corresponding attribute with:
l Unrestricted. In this case the user has all rights for all existing elements for a
determined dimension;
l Limited. In this case the user has rights only for the elements explicitly
defined as editable/visible. The definition of such elements is performed by
using an apposite management window accessible from the "Restrictions on
dimensions" window menu;
l By area profile. In this case, if the user belongs to an area profile he inherits,
as editable/visible, all elements related to that profile.
Page 49
Data Rights
Accounts rights
The management of the user rights on the account dimension can be accessed from
Setup & Admin / Users rights / Users rights / Users rights / Restrictions on dimen-
sions by selecting the Account restrictionssection.
The definition can be performed:
l by single accounts or
l by nodes of a hierarchy defined on the account dimension; it is possible to add
or delete from the nodes single accounts and/or lower level nodes.
Independently if a single element or a node is given, it is necessary to specify expli-
citly which are the accounts in visualization only, otherwise the account will be both
editable and visible to the user.
Restrictions on custom dimensions

The management of the user rights on custom dimensions can be accessed from
Setup & Admin / Users rights / Users rights / Users rights / Restrictions on dimen-
sions by selecting the Restrictions on Custom dimensions section.
The definition, enabled only if the custom dimension is managed, can be performed:
l by single elements of the custom dimension or
l by nodes of a not time dependent hierarchy defined on the custom dimension;
it is possible to add or delete from the nodes single elements of the custom
dimension and/or lower level nodes.
citly which are the elements in visualization only, otherwise the element will be both
editable and visible to the user.
Restrictions on categories
The management of user rights in the category dimension can be accessed from
Setup & Admin / User rights / User rights / User rights / Restrictions on dimensions
by selecting the Category restriction section.
We remind you that by default a new user has rights in editability and visibility on all
the contributor's categories.
l by single categories or
l by nodes of the categories grouping; it is possible to add or delete from the
nodes single accounts and/or lower level nodes.
citly which are the categories in visualization only, otherwise the category will be
both editable and visible to the user.
Page 50
Data Rights
Restrictions on original scenarios

The management of user rights on the original scenario dimension can be accessed
from Setup & Admin / User rights / User rights / User rights / Restrictions on dimen-
sions by selecting the Original scenario restriction section.
l by single scenarios or
l by nodes of the scenarios grouping; it is possible to add or delete from the
citly which are the original scenarios in visualization only, otherwise the original scen-
ario will be both editable and visible to the user.
Restrictions on consolidation scenarios

The management of user rights on the category dimension can be accessed from
Setup & Admin / User rights / User rights / User rights / Restrictions on dimensions
by selecting the Consolidation scenario restriction section.
We remind you that by default a new user has no rights on any consolidation scen-
ario.
l by single consolidation scenarios or
l by nodes of the scenarios grouping; it is possible to add or delete from the
citly:
l which are the consolidation scenarios in visualization only, otherwise the con-
solidation scenario will be both processable and visible to the user;
l if the entities belonging to the consolidation perimeter must be assigned in vis-
ibility to the user. This operation is very useful when the consolidation peri-
meter's structure does not match with the organizational structures with which
the application processes are performed, for example when in the consolidation
perimeter a cost entity is present (a sold entity) that typically will not be
present in the organizational structure but must be still visible to the user.
Restrictions deployment
During the saving, the system automatically performs the deployment of the restric-
tions definition on the dimensions generating, dimension by dimension, the detailed
list of the editable and/or visible elements.
Page 51
Data Rights
Restrictions on other dimensions

These restrictions are applied on the elements of the following dimensions:
l form;
l ETL Domains;
l ETL routines;
l ETL Jobs;
l routine closing;
l CDM documents;
l Production Control module data processing;
l attributes and work order types of the Expense Management module.
Except the last restriction type, these are secondary restrictions that do not limit
visible data but only the possibility for the user to use an ETL form or an ETL routine
or a closing rule or a CDM document or a Production Control module data processing.
While, as far as restrictions on attributes and the work order types of the Expense
Management module are concerned, these are restrictions that operate both on the
editability and on the visibility. If a user can manage one element of such dimensions
then he can also visualize it. The elements of these dimensions that the user can only
display must be explicitly specified.
By default in Tagetik any new user has management rights for all the existing ele-
ments. It is possible to limit such rights by defining the manageable elements manu-
ally.

For each user that is allowed to work on a determined application database it is neces-
sary to specify for each of the above mentioned dimensions if the user has all rights
for all the existing elements or specify manually the manageable elements. For this
purpose it is necessary to open the users table of the application database accessible
from Setup & Admin / User rights / User rights / User rights, then position on the
Other restrictions tab
Page 52
Data Rights
and set for each of these dimensions the corresponding attribute with:
l Unrestricted. In this case the user has all rights for all existing elements for a
determined dimension;
l Limited. In this case the user has rights only for the elements explicitly
defined as manageable. The definition of such elements is performed by using
an apposite management window accessible from the Restrictions on other
dimensions window menu:
l By area profile. In this case, if the user belongs to an area profile he inherits,
as manageable, all elements related to that profile.
Restrictions on forms
The list of forms a user can visualize can be accessed from Setup & Admin / User
rights / User rights / User rights / Restrictions on other dimensions, by selecting the
Form restriction section.
l by single forms or
l by nodes of the form grouping; it is possible to add or delete from the nodes
single forms and/or lower level nodes.
Page 53
Data Rights
ETL Restrictions
The management of this restriction type can be accessed from Setup & Admin / User
rights / User rights / User rights / Restrictions on other dimensions and then selecting
the corresponding section.
l by single elements;
l by nodes of the ETL or ETL Job or ETL Routine environments grouping; single
lowest level elements and/or nodes can be deleted or added to the nodes
Closing rules restrictions

The management of this restriction type can be accessed from Setup & Admin / User
rights / User rights / User rights / Restrictions on other dimensions and then selecting
the corresponding section
The definition is performed by single elements only because for these dimensions
there is no aggregation structure.
Restrictions deployment
During the saving step, the system performs automatically the deployment of the
restrictions' definition on the dimensions by generating, dimension by dimension, the
detailed list of the visible elements.
Page 54
Appendix
Appendix
Block user
Only the administrator user can block a user restraining him from accessing Tagetik.
There are several ways to block a user:
l temporary block. By enabling the Blocked Temporarily option present on
the Repository database's users table (Repository / Users and Roles / Users
and Roles / Users / Element) or using the Block / Unblock user utility (Repos-
itory / Users and Roles / Users and Roles / Users / Element / Actions ( )/
Remove users / Block/Unblock users) the administrator blocks temporarily the
access to Tagetik. The temporary block of a user can occur also when a user
types a wrong password at the login exceeding the number of allowed
attempts. In such case the system automatically blocks the user and in order to
allow him to access again the administrator must disable the above mentioned
option. It is important to notice that in this case the temporary block affects all
the databases the user can access
l block user / database relationship. After defining the roles, the admin-
istrator defines for each user the list of the application databases where he can
Page 55
Appendix
work so as to specify which applications the user can access and at the same
time for each database relates one or more roles so as to specify the list of the
activities he can perform (set of visible menus). At this step it is possible to
enable the Block temporarily option so as to deny the access to a specific
database. This possibility is particularly employed during the creation of a new
user so as to restrain the user from accessing the application and performing
what is enabled for his roles before the administrator has defined possible
restrictions in visibility and insertion/certification on data.
l Block for time limit exceeded. Tagetik allows to relate a determined user
that must work on the application only for a determined period of time
(because he has a fixed term contract, because he is on loan from another
office...) to a start date and an end of validity so as that if the login is per-
formed in a date that is not comprised between these dates the system does
not allow the user to access the application. It is important to notice that a user
with an expired date keeps the definition of the roles and of the possible restric-
tions so as that, if it is necessary to extend his expired validity or to make him
a definitive user, the administrator does not have to redefine the full para-
meterization of such user. The time validity of a user can be set from two dif-
ferent points:
o from the Repository users table (Repository / Users and Roles / Users and
Roles / Users / Elements). In this case the definition of the validity time
affects all the databases the user can access;
Page 56
Appendix
o during the user / database / role relationship step (Repository / Users and
Roles / Users and Roles / Users / users/roles Relationships or directly from
he users table via the Repository / Users and Roles / Users and Roles /
Users / Element / Actions ( )/ Details / users/roles Relationships window

menu). In this case the validity time affects only the database for which
the relationship is being defined;
l final block. Via the Delete users utility accessible from Repository / Users
and Roles / Users and Roles / Users / Element / Action ( )/ Users closings /
Delete users, the administrator can permanently block one or more users from
accessing the database. By blocking a user permanently, the system deletes all
his roles and the parameterization of all his restrictions. Tagetik always
records inside the audit log the operations performed through these utilities so
Page 57
Appendix
as to have always full control of who, when and how operated on data. A per-
manently blocked user is not physically deleted from the database but labelled
as Deleted (the Edit status field assumes this value). By default when the
Repository database users management window is opened, the deleted users
are not visible. To see them it is necessary to modify the filters present in such
window, particularly to delete the filter present on the Edit status attribute by
deleting the No value from the list;
l temporary block for maintenance. Tagetik provides monitor utilities that

allow to enable and disable the access of the users to the application and to the
single databases.
Password rules
Tagetik allows to define password validity criteria in accordance with the security
need of the relative organizations so as to guarantee the creation of safe and hard to
decode passwords. The level of security offered by the passwords depends on the
complexity of the passwords. The passwords with a higher level of complexity are
harder to decode and thus guarantee an higher security level.
The password security table can be accessed from Repository / Setup / Setup /
Authentication / Tagetik: password rules.
Page 58
Appendix
Each password rule is identified by:

l a code and a description:
l a duration expressed in days. By setting 0 it is possible to define a password
with no expiration;
l number of password expiration notice days that specifies how many days
before the expiration of the password the user, during the login step, receives a
warning of imminent password expiration and is suggested to modify it. By set-
ting 0 as value for this field, the user will never receive this warning until the
password is not expired;
l The "days after Password expiration the user will be blocked" that iden-
tifies how many days can pass after the password expiration before the user is
blocked in accessing the databases where he is enabled. Whether a user is
blocked the intervention of the administrator is required to remove the block;
l minimum and maximum length the password must have. The longer is the
password the better it is;
l number of special cipher and characters the password must have;
l minimum number of beginning letters namely not numerical characters
that must be at the beginning of the password;
Page 59
Appendix
l number of different beginning characters that identifies the number of

the first positions that cannot contain the same character. For example if this
number is three, the password aaabcde is not valid;
l maximum number of failures over which the user is disabled and will not be
able to access the application until the administrator unblock him;
l minimum number of different passwords that identifies the number of
passwords stored in the audit log that cannot be reused for the change of pass-
word.
Change password
Each user can change, whenever he wants, his own Tagetik password by the menu
User menu / Password ( ) at the top right of the home page. The system opens the
Change password window
The user has to:

l insert the old password;
l insert the new password. The chosen password must satisfy the password
rule associated to the user;
l insert the new password again so as that the system can verify its correctness;
l confirm the modification by clicking on the Change password button.
Change other user's password

The administrator user can:
l force a user to change his own password by enabling the Password to
change option present on the users table (Repository / Users and Roles / Users
and Roles / Users / Elements). The user whose password has to be changed, at
the next access will have to change his own password.
The system does not consider the setting of this option if the authentication
system is not the Repository.
Page 60
Appendix
l change the password of a user. In order to change the password it is neces-

sary to:
o select on the users table () the user whose password has to be changed;
o click on the selected user by the right button of the mouse and select the
Change password option or select the Actions ()/ Change password

menu
The system opens the Change password window
In this window the system displays the user who has to change his own pass-
word. In order to perform the modification it is necessary to:
o insert the new password. The selected password has to satisfy the pass-
word rule associated to the user;
o insert the new password again so as that the system can verify its cor-
rectness;
o confirm the modification by clicking on the Change password button.
Recode user
Tagetik allows to change the codes assigned to the various users.
The recode utility can be accessed from Repository / Users and Roles / Users and
Roles / Users / Element / Actions ( )/ Users closings / Recode Users and affects all
the users previously selected in the users table.
In order to recode the users codes it is necessary to:

l select in the users table the users to recode. Let us assume we want to
recode the users test1, test2, test3 and test4 into test001, test002, test003,
test004;
l then access the Actions ( )/ Users Closings / Recode users window menu
and specify the new user code for each user to recode;
Page 61
Appendix
l click the Run button.

At this step, the system performs a series of preliminary checks in order to verify
that:
l the code of the user to recode does not begin with $;
l the new codes do not include forbidden characters;
l the new codes are not already present in the table, namely that the new user's
code to recode does not already exist.
and then
l creates a new user as copy of the user to recode by assigning him as code the
new one and labelling it as From recoding (the Edit status attribute
assumes this value);
l blocks the user with the old code permanently. Namely, the utility never per-
forms deletions but the old users are just labelled as Recoded (The Edit
status attribute assumes this value) and remain in the database. By default
when the users table management window of the Repository database is open,
the recoded users are not visible. In order to see them it is necessary to
modify the filters present on this window, particularly to delete the filter
present on the Edit status attribute by deleting the Recoded value from the
list;
Page 62
Appendix
The users recode data processing is a potentially very long operation, above all if
performed on several users having access to several databases. Thus it is recom-
mended to run it on few users at a time.
After recoding an user, the audit log of the old codes (if the recode operation is run
several times the old codes might be many) can be consulted from Repository / Users
and Roles / Users and Roles / Users / Element / Actions ( )/ Users closings / Show
recoded users. The system displays the full chain of the recoding performed on the
selected user (from the oldest code to the more recent one).
Thus if, for example, for the user test1 that was subjected to two recoding, first in
test01 and then in testA01, the system displays:
Page 63
Appendix
Page 64
Glossary
Glossary
A
account
The Account represents the basic nature of each information
stored in Tagetik. In the account dimension the user can open
any measure or metric, both financial and statistical.
actual
The Actual represents a set of information which have already
occurred in relation to a past period For example, the costs
incurred in January are considered actual costs in February
application database
An application database is a database where all data and data
sizes concerning the application are stored. A typical installation
of Tagetik consists in a Repository database where all the inform-
ation about the system management are stored (users, roles,
licenses etc.) and an application database for each application to
manage
application language
The Application Language is the interface language, namely the
language by which the application is displayed (menu items,
headers, fields names in management windows, error mes-
sages)
audit
The Audit is the means by which Tagetik keeps trace of all the
activities done and all the possible errors occurred in the course
of time. The audit is aimed at allowing the user to keep trace of
all the steps of the activities (directly run by the system or with
the intervention of the user) run during a certain time interval.
B
budget
The Budget represents a goal that the Entity is meant to achieve
in a certain lapse of time. Usually the Budget is related to a one
year long time horizon (for example budget 2003); in case of
Page 65
Glossary
more that one year we talk about plan. For our work area, the
budget is a forecast of revenues, costs, actual balance sheet and
cash flow that the Entity is engaged to achieve in a determined
lapse of time
C
category
In Tagetik the Category dimensions allows to classify and seg-
ment data (in particular the structures) and to trace the way data
is generated
cell field
A cell field allows to recover and display within a form the attrib-
utes of the dimensions used as filters
consolidation currency
The Consolidation Currency is the currency by which the con-
solidation is generated. It usually corresponds to the currency of
the Holding (but not necessarily)
consolidation scenario
The Consolidation Scenario is the scenario that indicates the
entity that defines the characteristics of the consolidation peri-
meter: the Holding, the entities to consolidate, the consolidation
methods,the consolidation currency, the data original source
scenario etc. On this type of scenario are stored "consolidated"
data that cannot be modified manually. The Consolidation Scen-
ario is also the rule that explains Tagetik how to consolidate the
entities of a determined consolidation perimeter.
currency
The Currency is the national currency in which a transaction or a
financial statement are performed.
custom dimension
A Custom Dimension is a dimension that allows to meet specific
business model's needs (products, clients, cost centres, ...).
Tagetik allows to define and manage up to five custom dimen-
sions
Page 66
Glossary
D
data entry mode
The Data entry mode allows the user to insert new data and to
modify data present in a data entry form
data processing
A Data Processing is a process that works on data. It reads input
data and generates output data according to built in rules (that is
encoded within the system) or rules defined by the User.
database
A database is a collection of information set to be easily accessed
for consultation, modifications and updates
design mode
The Design mode allows to modify a form structure
dictionary
A Dictionary is a list of admitted values for an ETL dimension
document currency
The Document Currency represent the currency bay which a cer-
tain operation has been performed (regardless of the currency of
the entity that performed it)
drill down
The Drill down utility allows to analyze the single parts aggreg-
ated data is made up of
E
ETL
The ETL (Extraction, Trasformation & Loading) is a completely
configurable engine able to extract data from external sources
such as Excel, text files, warehouse data, ERP systems (SAP,
Oracle or Microsoft) or from a Tagetik database; it is able to
change and load data into several custom dimensions, both
internal (Tagetik database) and external (generic database,
Excel or text file) to Tagetik.
Page 67
Glossary
ETL dimension
An ETL dimension is a column of the staging table where the ETL
engine copies data extracted from one or more external sources
ETL domains
An ETL Domain represents a macro container that includes all
attributes and information concerning a ETL rule (configurations,
extraction formats, transformation and load rules)
ETL routine
An ETL Routine is the smallest data processing unit which can be
run in an ETL process and contains all the routine run information
and the link to the details for the data extraction, transformation
and loading
event scenario
The Event Scenario is a fictitious scenario used by Tagetik to man-
age events by date, particularly the events of the group structure
F
financial statement template
A Financial Statement Template is a particular aggregation struc-
ture of accounts or accounts / custom dimension which is gen-
erally used to create standard financial statement templates
(P&L and IAS balance sheet, IV directive, direct / indirect cash
flow) but also KPI and other needed indexes for the reporting
fiscal year
A Fiscal Year represents the financial year to which the entity
management is related. Usually the fiscal year accrues from the
1st of January to the 31st of December; but different dates can
be also chosen. Tagetik does not manages an out-and-out fiscal
years table; rather, their definition is implicit in the definition of
the scenarios.
forecast
The forecast is the budget data udpate. The forecast is elab-
orated during the course of the year when the Entity closes the
first actual situations. When the actual is compared to the
budget, differences can occur; these originate new forecasts
exactly named forecasts The Forecast is related to a specific
month: for example in March the forecast is made through the
Page 68
Glossary
actual data of January - March and a new forecast for April -

December
form
a Form is a special Excel spreadsheet used by Tagetik inside its
reporting and data entry "unified" system based on Microsoft
Excel to interact directly with the application database of Tagetik
so as to display / extract database information and save data
inserted by the user into the database.
form filter
A Form Filter is a filter type which affects the whole form
function
A Function is a basic operation the user can perform. Typically
the functions are the management of tables, data processing,
reports. In most cases a function corresponds to a menu key or
to a window menu; in some cases to more simple operations.
The functions definition is only aimed at the roles definition
G
grouping
A grouping is a multilevel structure with unlimited depth and
multi-parent (each node or element of the dimension can be
related to several parent nodes) which allows to group / organize
a set of elements in order to meet the various business needs
H
hierarchy
A Hierarchy is a closely hierarchical multilevel structure that
allows to aggregate / sort a group of elements in order to meet
the various business needs
holding
The Holding is the Entity that controls all the other entities of the
group by the ownership of shareholdings (control or anyway rel-
evant shareholdings). It is the entity that presents the con-
solidation financial statement
Page 69
Glossary
M
matrix
The Matrix identifies the forms area in which data present on the
application database are displayed. Technically, the matrix rep-
resents the combination of several filters to apply to the Tagetik
dimensions so as to have the set of data to display, like a SQL
query
matrix filter
A Matrix Filter is a filter type which affects the whole area of a
form matrix and thus not only the rows or the columns
module
The Module represents a set of functions. Each function belongs
to one module only. The modules definition has two goals: - to
simplify the roles definition. Indeed, when assigning the func-
tions to a role, it is possible to use the module to assign to the
role all the functions belonging to the module. to check the sys-
tems functions accessibility according to license purchased by
the customer. The list of functions a module is made of is preset,
and the users can not modify it
N
navigation mode
The Navigation mode allows the user to display data of a report
or of a data entry form. When the Navigation mode is used it is
not possible to edit data
O
original scenario
The Original Scenario is the scenario used by Tagetik for all the
data inserts: Amount, Preconsolidation and Consolidation Adjust-
ments. It includes the concepts of fiscal year and data version
(for example 2008ACT to describe the fiscal year 2008 and the
actual data version, or 2008BDG to describe the fiscal year 2008
and the budget data version, or 2008F6 to describe the fiscal
year 2008 and the forecast version edited at the end of June)
Page 70
Glossary
P
parameter
A Parameter is a particular type of filter which can be used inside
a form whose value in unknown until the form is run
period
The Period represents the basic unit by which the fiscal year is
divided. Typically the Period represents the month (it manages
12 Periods) but a manual management is also possible in order
to meet the user's business needs.
period length
The Period length is a specific dimension of the Reporting which
allows to manage within a form aggregated data for example in
quarters, semesters, etc from cumulated data present on the
Tagetik application database
process
The Process represents a business cycle (budget, actual, fore-
cast...) having a start date and an end date. Each Process: - can
have a single expiration date or several intermediate expiration
dates; - is repeatable with different expiration dates (monthly,
quarterly, half-year, annual); - can run on the entire data model
or on a part of it
R
Repository
The Repository is a centralized database where the users who
can access Tagetik, the roles (both system and custom) assigned
to the users that define the activities an user can do are man-
aged
role
A Role define the activity that a User can do in Tagetik. A role is
described by a list of functions, that is a list of simple operations
of the application that a user can choose and perform. Typically
the functions are: management of tables, data processing,
report; usually a function corresponds to a menu key or to a win-
dow menu. The Role defines if the User can use each function
fully, only in display mode (as far as tables are concerned)or if he
cannot use it at all.
Page 71
Glossary
S
scenario
The Scenario represents, together with the period, the time
dimension of Tagetik and includes also the concept of data ver-
sion
scheduling
The Scheduling is the delayed run of a data processing or a job; it
defines parameters and launch-time
SharePoint
SharePoint is the Microsoft cooperative platform, based on .NET
Framework, that provides a complete environment for the man-
agement of files, contents, business processes, etc
snapshot scenario
The Scenario Snapshot is a scenario where to "Freeze" data
before further modifications
SQL model
A SQL Model is a SQL language query that can be simply used in
the management windows where an ETL filter is employed
T
tab filter
A Tab Filter is a filter type which affects the whole area of a tem-
plate present in the form
tables language
The Tables Language is the language by which the metadata ele-
ments' descriptions are displayed
template
A Template identifies each Excel sheet present inside a form
U
user
The User is who can access Tagetik
Page 72

User Management Manual

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

User Management Manual

Enviado por

Direitos autorais:

Formatos disponíveis

Users management

Copyright 2012 Tagetik - All Rights Reserved

Using an analogy we can say that:

Thus in Tagetik there is:

Tagetik supports the following external authentication mechanisms:

word. This authentication system allows to implement a Two Factor Authentic-

By using the "Default authentication " Tagetik's users authentication system,

Where to configure the authentication mechanism

l directly in the abovementioned management window. In this way, whether to

Authorization: role based access

Set the user rights on metadata

Create a new user

A user can be created in two different ways:

Thus in Tagetik there is:

Moreover for each user it is possible to:

porarily option or using the Actions ( )/ Remove users / Block/Unblock user

At single window level the user can:

Authorization: role based access

System roles and custom roles

System role Actions

System role Actions

$ADMINISTRATOR A user with this role gets advantages as unique

$CONSOLIDATOR A user provided with this role has the advantages

$SYSADMIN A user with this role has advantages as system

System role Actions

$USER A user provided with this role has the advantages

Custom role creation

Each custom role is identified by:

l a list of functions, namely a list of simple operations of the application a

Actions ( )/ Details / Enabled functions

Example 1: Let us assume we want to define a USER_EXCHANGE_RATE custom role

Users / Roles relationship

If we look at the image above we notice that the User1 :

This relationship can be performed directly, namely by specifying an application data-

and Roles / Users / Element / Actions ( )/ Details / users/roles relationships

For each user / database specify:

A user can be a reference user:

Create area profile user

Create a user belonging to an area

In Tagetik the user rights on data are:

The activities the user can perform on the nodes are:

It is important to notice that:

l rights on accounts, original scenarios, categories, custom dimension.

l rights on consolidation scenarios. These rights operate both on the vis-

l rights on WF Model. These rights operate on the possibility of processing or

l rights on attributes and Work order type of the Expense Management

l rights on forms and ETL routines (automatic loading procedures), closing

The definition of the user rights can be performed:

User rights on entity dimension

Restriction type definition

and set the Entity and task attribute with:

agement window accessible from the window menu Actions ( ) / Restrictions

( ) / Restrictions entity and task window;

The window is divided into five different tabs:

which are not approval/submission;

definition is performed in the Generic list Task tab of the Restriction

2 - Contributor nodes rights

3 - Consolidator nodes rights

definition is performed in the Generic list Task tab of the Restriction

5 - Generic task list . See Restriction on tasks.

This window is divided in seven tabs:

The records sorting can be modified as follows:

Example 3: Management of visibility different from editability. User with editability

In order to limit the user in submission on the consolidation node it is necessary to