One User’s experience of a CLS tenant can be totally different from another’s and it very often is. This is because a sophisticated interplay of factors come together to determine who and what a User can see in the system and what s/he can do with this. These factors include a User’s:
There are two kinds of management hierarchies that can be set up in the CLS:
The items in the hierarchy are Users, e.g. User B reports to User A
The items in the hierarchy are Positions, e.g. the Factory Manager Position reports to the CEO Position.
In practice this is expressed through actual Users, so that those Users with the Factory Manager Position report to those Users with the CEO Position. Note that a Position can have one or more Users.
Both options enable reporting hierarchies such that one item in the hierarchy can report to another item in the hierarchy, that itself reports to another item in the hierarchy, and so on. Each item in these structures ‘sees’:
Thus, Users/Positions in a hierarchy have Users/Positions reporting to them both directly and indirectly. Every User/Position reports to another higher up the chain, except the one at the top.
Once Users have staff reporting to them via involvement in either kind of hierarchy, they become managers and are automatically given the Implicit Role of User Manager. Note that this is different from an Explicit Role, which is one explicitly allocated to an individual User. You can make a User a manager of another User outside of a reporting hierarchy by using Explicit Roles, but this will not be part of a hierarchy and hence not show indirect reports.
To return to reporting hierarchies, if Users are managers in a reporting hierarchy, even those with a Basic User Role are given the rights to manage the staff that report to them, both directly and indirectly. The power of the User Manager Role can be extended and fine-tuned by editing it and changing the settings for Securable areas of the application, see Settings > Roles for details.
As an indicative example, Users who become managers through a management hierarchy will see:
Depending on whether the appropriate plug-ins are installed, they may also see:
Of course, an individual User Manager is not limited to these; the list is expanded through, for example:
Note that if a User is the manager of another User who has, say, a Tenant Admin Role against a particular Catalogue Item, the manager User does not also have access to this Catalogue Item because management is about people and the progress of people.
The two management hierarchies are somewhat different. You set up a User hierarchy by:
You set up a Positions hierarchy by:
The differences between the two kinds of management hierarchies are summarised below:
|Direct and Indirect reports?||yes||yes|
|Reports to||another User||another Position|
|Reports to set up||for a User||for a Position|
|Reports to shown at||User details screen||Position details screen|
|Reports on set up||for the User(s) underneath this User in the hierarchy||for the Position(s) underneath this Position in the hierarchy|
|Reports on shown at||no||Position details screen|
|User Reports to >1 User?||no|
A User can only report to one User.
A Position can report to a Position that has multiple Users holding it, e.g. a job share.
|Report to User/Position another Org Unit?||yes||yes|
Positions are an optional CLS feature and are oriented to reporting. They are commonly used to create a hierarchical data structure for reporting purposes. In this way they play an important role in the CLS Security Hierarchy. Each Position belongs to one Organisation Unit and can report to another Position, not necsessarily in the same Organisation Unit. A User can only hold one Position, which must itself belong to their Organisation Unit. A Position can only report to one other Position, although multiple Users may have that Position.
Positions enable reporting hierarchies because one Position can report to another Position that reports to another Position, and so on. As discussed in the Introduction, a User with a Position in this chain sees material relating to the Users with the Position(s) that report to it, that is, direct reports. The same Position also, in effect, looks over the shoulder of the Users with Position(s) that report to it and sees their own reporting perspective(s), plus those of the Position(s) beneath them, etc, that is, indirect reports.
The example below illustrates this and is based on the very simple Position-to-Position reporting hierarchy that we have already seen. On the right is a list of the Users who hold the different Positions in this hierarchy.
In this example, the Factory Manager Position inspection screen would show:
Its screen has links to:
Thus, the full reporting relationships in the example above are:
|Position||Users who hold this Position||Reports To|
|Sees Direct Reports on|
|Sees Direct Reports on|
|Sees Indirect Reports on|
|Sees Indirect Reports on|
|User with this Position has User Manager Role|
|d e f|
g h i
|Factory Manager||b||CEO||Factory||d e f||–||–||YES|
|c||CEO||Office||g h i||–||–||YES|
|Factory||d e f||Factory Manager||–||–||–||–||NO|
|Office||g h i||Office Manager||–||–||–||–||NO|
Note that unlike in this example more than one User can hold a management Position.
Positions can usually be managed by selecting Manage People > Positions.
Note that many Users will not be able to see this menu item because of the security system. For authorised Users it will be visible if Positions are enabled in the system and the Relationship Management Type is also set to Positions, see Setting Up Positions.
Management relationships in the CLS can be run in different ways, as discussed in the:
Positions are used explicitly for the management hierarchy and the Position function is visible in the Manage People menu.
Here the management hierarchy is present in the system, but less visible. The Position function is not present in the Manage People left hand menu.
There is no Relationship Management or Position functionality at all. The rest of this document is not relevant if option 3 is chosen.
To set up Positions go to Settings > Tenant Settings.
Click the chevron next to Organisation and then click in the drop-down box next to Relationship Management Type. Click and select an option:
Click Save Settings.
Select Manage People > Positions > Add Position.
Complete the Position form details:
Note that the system does not list any positions in the drop-down list if their selection would result in a circular reporting hierarchy.
Note that Custom Attributes can be added to Positions. If they have been added they will be seen in Edit mode under the heading Extended Information.
If there are multiple Users and Positions to create then the import function can be more efficient.
Select Manage People > Positions > Import Positions.
In the next screen click the link below:
This takes you to Mange People > Users > Add or synchronise Users from spreadsheet function. With this User import functionality Positions can be created at the same time as Users are created. A new Position will be created through this process if the data entered in the Position columns for a User does not already exist.
The data is entered via a spreadsheet. One important decision is the Data Source. If you select Sync data from HR system the CLS will inactivate any Users that are present in its system but are not present in the imported spreadsheet, i.e. not in the client’s HR system. Thus, the master file for Users, Positions etc is the client’s HR system. Note that this approach only inactivates Users who are not in the imported spreadsheet; it does not inactive Positions that are not in the spreadsheet.
This is not the case when you select Data Upload, which adds Users and updates existing ones but does not deactivate Users who are not in the spreadsheet.
There are a number of aspects to the import process:
The following are the settings that have been made possible by the Default Settings screen (3).
The Data page in the template shows an example row. A new Position will be created through the import process if the data entered in the Position fields for a User does not already exist. Remember that a Position is in the same Org and Org Unit as the User.
The Supported Attributes page gives further information about the fields in the template. The fields that are of particular interest to Positions are indicated in the screenshot below. Note that Position Classification Id and Position Classification Name are not used in an import.
For a Position-to-Position manager relationship enter data in the:
For a User-to-User manager relationship only enter data in the:
This part of the CLS allows you to set the default specifications for a User Import. Most of the fields have already been explained in, with the exception of:
When the data generated from a client’s HR system is imported into the CLS there sometimes needs to be a correlation established between the names that the HR system call each data field and the names that the CLS calls them. This correlation is called a Column Mapping.
To look at the a Position details screen, navigate to Manage People > Positions and click the name of the Position.
This gives you access to information about:
The Search feature allows you to quickly find a Position. Search is only required when there are a large number of Positions in the list.
To search for a Position select Manage People > Positions.
To inspect a Position navigate to Manage People > Positions and click the name of the Position.
Authorised users will see the Edit Position button on the details screen, allowing them to edit details of the position.
Edit details as required see Manually adding a Position for details and click Save Position.
Note that once a Position has been saved, it is not possible to change its Organisation unit. This restriction exists to avoid data integrity issues through dilemmas such as:
Whenever such potential data integrity problem scenarios arise, the CLS errs on the side of maintaining data integrity; that is, rather than making an assumption about what a User wants to do (and suffer potentially harmful side-effects), it stops the User from doing it. Thus to change the Organisation Unit for a Position, the best approach is to create a new Position, and move Users into it.
Be aware that if Positions and Users are usually imported see Importing a Position you should not edit them in the CLS because they may be overwritten when the next import is run. This is because a key concept when importing is often that the master file for Users, Positions, etc is held in the client’s HR system, not in the CLS.
The archive feature removes the Position item from the list of active Position items. This assists in keeping the list to a minimum. The archived item can be accessed in the Archived tab. Generally speaking, archived items are ones that are no longer required.
There are two methods for archiving a position. These are:
Locate the Position and edit it.
Select Manage People > Positions.