Also just want to make it clear that this is designed to meet the use case of one user with multiple jobs. As such the behaviour is designed for that use case.

There is a separate, but related use case of having more than one manager acting as a user's manager in a single job. We've looked at if we can solve that at the same time but unfortunately it is technically quite difficult to handle. There is a potential solution, that we could add later, but it's not going to be in scope for version 9.

I mention that because some people may have thought they could meet the multiple managers per job use case by having multiple jobs - e.g by creating two jobs for a user then assigning different managers to each. I just want to make clear that won't work - for the reason described in the second to last paragraph above - the manager relationship is constrained to the specific job it is linked to.

Simon

Option 1 immediately introduces issues of data inconsistency (what happens if one of the "Other User Fields" is first name, surname, etc. and the two rows have different values for example).

Option 2 is a horrible way to structure data from a normalisation perspective, and I would really hope that no commercial HR system would do it that way. It would make the ability to have N positions very tricky (because you wouldn't want to have infinite numbers of columns, and every job custom field would require N additional columns).

To give you a real world example, our HR system has a 1 to many relationship between Employee (the person) and Assignment (the role). There is a 1 to many relationship between Supervisor's Assignment (the manager's role) and Assignment (the employee's role):

Happy to provide any other information you might need.

Hi Simon,

It's probably worth pointing out that systems such as SAP are completely configurable to the client's requirements so there is no standard way that clients store employees and jobs associated.  There is always a degree of discussion with their IT team (normally quite lengthy and painful) in how to structure the data sent to us.

It's also not guaranteed that they work off a defined list of job roles or descriptions and in a lot of cases the job roles are manually input by the managers so there is a lot of disparity between spellings and actual naming for the same job.

Something we also run across a lot is that a job role is different from the job description:

job role = The actual job that the employee holds has an ID.  It's important to realise that this isn't the description for the job.  e.g David and Jo are both cleaners and their job role IDs are 123 and 456 respectively.  The ID would be unique to the individual even though they do the same job.

job description = the title of the job e.g cleaner.  They might have an ID associated with this but not always and that is what we then link to the positions hierarchy if the client has any use for it.

I'm not sure if that makes any difference to your work but it's a nice to know.

We have two large clients using AX and SAP as their HR systems who have multiple job roles and they both follow the same data structure:

• SAP holds a single employee record with an employee ID.
  
• SAP lists the different job roles under the employee ID.  There is no link to a role description
  

My preference is for option 3 (for all the same reasons as Dan has outlined)

And regarding the manager hierarchy I think that your suggestion is fine.  I personally would have defined the manager links the other way round, so that instead of a learner having managers listed against them, you define who a manager's line reports are against the managers record.  That way managers already have the concept of multiple line reports stored against them, which I think makes it easier to set up multiple managers for a single user with the same role (you just add the line report user account to more than one manager and define them as primary/secondary etc).

David

We have implemented a number of projects with multiple positions. Migrating these across would be easier with Option 2 since we have taken this route via custom development. However, going forward, we believe that Option 3 is the better solution for reasons already outlined by others

Alex Büchner - Synergy Learning

Hi,

Yes, I agree with others in that I think Option 3 is the best solution, our HR systems is exactly the same as Dan's .  I also agree that the manager hierarchy diagram is the way to go.

Regards
Steph

Hi 

I received this reply from one of my clients in posing the question about multiple roles.

"Project environments come to mind here.  Alternatively it may be better to refer to this a secondments (a more universal concept that would have the similar characteristics but is possibly more intuitive to non-project people).

The unique attribute of a secondments is that they're temporary and come an end after a given period.  Staff are normally seconded to the initiative and report into an alternative manager.  Secondments often consume only a portion of an employees FTE.  The thread caters well to the concept but I wonder if they've considered assigning a start / end date for the job concept."

I just thought I'd share the insight.

Regards

Markus Du Plessis - Strat Cafe

Hi Simon, 

Option 3 seems to fit our needs. As mentioned from the others here, most of the clients have different structure (mostly from SAP) of the data they provide us with. 

As about reporting “down the hierarchy”, what are your plans for a standard look deeper down the hierarchy? We have clients, who have the requirement to look down the three structure of their subordinates with possible restrictions at each level, In your example that will be an access bellow the User: E, so for example User D will have a look of the users, who are the subordinates of User E and so on, until the last position in the three structure.  

Regards, 

Georgi.