Welcome to the Janison Academy help portal

Positions

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:

  • membership of an Organisation and Org Unit.
  • Role(s), see Settings > Roles.
  • membership of Group(s).
  • involvement in a Position-to-Position or User-to-User management hierarchy.

There are two kinds of management hierarchies that can be set up in the CLS:

    1. User-to-User

The items in the hierarchy are Users, e.g. User B reports to User A

    1. Position-to-Position

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’:

  • Direct reports. This is material relating to the items that report to it (lists of Users, enrolments, etc).
  • Indirect reports. In a sense the item also ‘looks over the shoulders’ of all the items beneath it in the hierarchy. So it also sees what the items that report to it see, plus what the items that report to them see, plus the level(s) beneath them, and so on, right to the bottom of the hierarchy.

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:

  • A list of the Users managed by them, both directly and indirectly (and including themselves) in Manage People.
  • Enrolments and related functions (e.g. Approve Learning) for those Users in Manage Learning.
  • Access to Customisable Reports for those Users in Manage Learning.

Depending on whether the appropriate plug-ins are installed, they may also see:

  • CPD displays for those Users in their own My Learning screens.
  • Access to CPD and Competencies for those Users in Manage Learning.

Of course, an individual User Manager is not limited to these; the list is expanded through, for example:

  • Settings in Securable areas of the application that expand the power of the User Manager Role.
  • Other Roles that may have been added to the User through User Extra Roles.

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:

  • adding or editing Users, starting at the top so that reports to can be completed for subsequent Users further down the hierarchy.

You set up a Positions hierarchy by:

  • creating the Positions, starting at the top so that reports to can be completed for subsequent Positions further down the hierarchy, then
  • assigning Positions to Users using the add/edit User screen.

The differences between the two kinds of management hierarchies are summarised below:

 Management Hierarchy
User-to-UserPosition-to-Position
Direct and Indirect reports?yesyes
Reports toanother Useranother Position
Reports to set upfor a Userfor a Position
Reports to shown atUser details screenPosition details screen
Reports on set upfor the User(s) underneath this User in the hierarchyfor the Position(s) underneath this Position in the hierarchy
Reports on shown atnoPosition details screen
User Reports to >1 User?no

A User can only report to one User.

yes

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?yesyes

Position Management

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:

  1. the Position that the Factory Manager Position reports to and the only User who holds that Position.
  2. the Position that reports to the Factory Manager Position and the Users who hold that Position.

Thus, the full reporting relationships in the example above are:

PositionUsers who hold this PositionReports To

Position

Sees Direct Reports on

Positions

Sees Direct Reports on

Users

Sees Indirect Reports on

Positions

Sees Indirect Reports on

Users

User with this Position has User Manager Role
CEOaFactory Manager

Office Manager

b

c

Factory

Office

d e f

g h i

YES
Factory ManagerbCEOFactoryd e fYES
Office

Manager

cCEOOfficeg h iYES
Factoryd e fFactory ManagerNO
Officeg h iOffice ManagerNO

Note that unlike in this example more than one User can hold a management Position.

Other notes:

  • Circular reporting hierarchies are not permitted in the CLS.
  • A Position does not have to report to another Position if desired.

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.

Set up Management Relationships

Management relationships in the CLS can be run in different ways, as discussed in the introduction:

    1. Position-to-Position manager relationships

Positions are used explicitly for the management hierarchy and the Position function is visible in the Manage People menu.

    1. User-to-User manager relationships

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.

    1. Not at all: Positions are disabled within the system.

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:

  1. Positions for Position-to-Position management
  2. Report to User for User-to-User management.
  3. None

Click Save Settings.

Manually Add a Position

Select Manage People > Positions > Add Position.

Complete the Position form details:

  1. Enter an Organisation and Organisation Unit
  2. Enter a Name and Identifier
  3. Click in the Reports to box and select a Position from the drop-down list if desired.

Note that the system does not list any positions in the drop-down list if their selection would result in a circular reporting hierarchy.

  1. Check the box to make the Position Active.
  2. Enter a Description if desired.
  3. Click Save Position.

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.

Import a Position

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.

Specification for the Import

There are a number of aspects to the import process:

  1. Click to download the CLS Template and fill it in, see Template for Import.
  2. Choose the Data Source from the drop-down menu as explained above.
  3. Click Default Settings if you need to go to Settings > Spreadsheet Import. Here the default import settings can be edited, including the ability to manually override them in the import process (below), see Settings for User Import.
  4. Click Define column mappings to examine and, if necessary, change the correlations between the CLS and the client’s HR system, see Define Column Mappings for HR Synch.

The following are the settings that have been made possible by the Default Settings screen (3).

  1. Click the checkbox to allow the update of existing User records if the imported data differs from that in the CLS.
  2. Click the checkbox to allow the creation of any Groups specified in the spreadsheet but not found in the CLS.
  3. Click the checkbox to specify that any Group memberships a User already has that are not specified in the import file will be inactivated. This only applies to group types specified in the import file.
  4. Click the checkbox to specify that any existing custom attributes of type list can have list items created during the import process if they exist in the spreadsheet but not in the CLS system.
  5. Click the checkbox to specify that new Users will receive a welcome email with a customisable message. Click View Email to see the current email message.

  1. Click the checkbox to specify that any Org Unit specified in the spreadsheet that is not found in the CLS should be created. Any Org Units in the CLS that do not have associated Users will be deactivated.
  2. Click the checkbox to skip the evaluation of an imported password’s strength.
  3. Click the checkbox to allow a User’s password to be changed to the one in the spreadsheet.
  4. Enter an email address for communication of the results
  5. Upload the import file from your local browser by clicking Select File.
  6. Click Import and email result.

Template for Import

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.

c

For a Position-to-Position manager relationship enter data in the:

  • Reports To Position Id: the Position that this Position reports to.
  • Reports To Org Id: the Org Id that the Reports To Position belongs to.
  • Reports To Org Unit Id: the Org Unit Id that the Reports To Position belongs to.
    Must be used in conjunction with the Reports To Org Id column.

For a User-to-User manager relationship only enter data in the:

  • Reports To User Id column

Settings for User Import

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 Specification for the Import, with the exception of:

  1. Click the checkbox to globally disable the manual override, so that none of the settings can be customised for a particular import.
  2. Click the checkbox to disable an individual manual override so that the setting cannot be customised during an import.
  3. Click to hide the import template link.
  4. Set the maximum number of Users to be imported using Web Role.
  5. Click Save

Define Column Mappings for HR Synch

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.

  1. The existing mapping is shown on this screen.
  2. The mapping can be modified by means of a Spreadsheet. Click Select File to read a correlation file and redefine the mappings.
  3. Click Define Mappings to save them.

Inspect Position Details

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:

  1. the Organisation Unit it is attached to.
  2. the number of Users who have the Position. This is a hyperlink to a list of these Users.
  3. who the Position reports to (if set), with hyperlinks to that Position and the User(s) who hold it.
  4. who reports to the Position, both directly and indirectly: hyperlinks to the list of Users and to the Position(s).

Search for a Position

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.

  1. Click Search for Positions and a search field will appear.
  2. Enter search text.
  3. Click Search.
  4. The search results will appear in the Display Name column.
  5. To perform another search click Reset Search.

Edit a Position

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:

  • If a Position’s Organisation Unit is changed, should all Users in the Position also have their Organisation Unit changed?
  • During a spreadsheet import, if the import process discovers that a Position has a different Organisation Unit from the previous import, should it create a new Position, change the Position’s details, or throw a validation error?

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.

Archive a Position

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:

  • Via Edit Position.
  • Via Position List.

Archive via Edit Position

Locate the Position and edit it.

  1. Uncheck the Active Box by clicking it.
  2. Click Save Position.

Archive via Position List

Select Manage People > Positions.

  1. From the list of Positions click the check box to the left of the Position you want to Archive.
  2. Click Archive.

Topics on this page