Aggregate main person based on primary contract
Bernard Moeskops
Currently the aggregation has 2 automatic scenarios. 1. transfer disabled: newly added persons contracts move to existing main person. 2. transfer enabled: existing contracts move to new main person. I think it should be possible to choose the main person based on where the primary contract comes from. Now you cannot force hierarchy upon the main person choice, but it is FIFO or FILO.
R
Ronald Knaap
bump
We are experiencing the same issue within our organization and would very much like to see this addressed.
In our situation, students transition from secondary education (VMBO) to vocational education (MBO). They are often registered in the MBO source system several months before their current contract ends. At that point, aggregation works correctly and the existing VMBO person remains the main person.
However, when the MBO contract becomes the primary contract, the main person is not automatically re-evaluated. As a result, the old source remains the main person even though the student has fully transitioned to MBO.
This creates manual work for us every year to correct these persons. It also has a wider impact in our environment, as we use different security groups and configuration settings depending on the student's source and type of education. When the wrong person remains the main person, these groups and other settings do not transition correctly either.
With a recurring and predictable transition like this, manual intervention should not be necessary.
We would therefore strongly support automatically re-evaluating the main person when the primary contract changes.
Ramon Schouten
I am probably misinterpreting this, but to me it seems the desire is to automatically calculate the main person based on the primary contract.
This is already the case if I'm correct (also according to docs: https://docs.helloid.com/en/provisioning/persons/person-aggregation/automatic-transfer.html)
Bernard Moeskops could you elaborate on the use case?
Bernard Moeskops
Ramon Schouten: You are not misinterpreting, but in my case I want to always have the main person that holds the primary contract currently. I am not 100% sure but from my testing it seems that the main person does not automatically change after it is merged. So let's say the primary contract changes on an already merged person, the main person does not automatically change.
R
Roel Assenmacher
Bernard Moeskops: I second this. The main person should automatically change to the person with the active contract if the other contract expires. Or there should at least be an option to manually change the main person of two (automatically) merged persons.
D
Dirk-Jan van Meeuwen
Maybe you could solve this issue in your HR source system? That's the place were we've tackled this issue.
We've created a free field in our HR system were we put the employee ID of the main person on the 'sub'-person. Our importscript has two get-actions. The first get-action is to import all the employee's with an empty main person field. The second get-action is to import all employee's with a filled main-person field. All the contractinformation from that get-action is added to the right main person in HelloID.
Now we didn't need the aggregation-function in HelloID.
Bernard Moeskops
Dirk-Jan van Meeuwen: Thanks, that's a solution indeed but the systems need to be seperated in this specific case. The main system is already very heavy and has no possibility for an extra field.