0
Declined

Org Unit flattening

Carol Wapshere 3 years ago updated by anonymous 2 years ago 2

This applies to other HR data feeds as well, not just Aurion.

HR systems typically give us the Org Unit hierarchy in parent-child format. However we need to "flatten" this against person objects so we can use the values for group population and attribute flows.

- The number of Org Unit levels will differ from organisation to organisation

- There will be a mapping between level and org unit type - for example "Section" may be level 4.

- There may be gaps in the Org Unit hierarchy - for example a level 4 org unit that is the child of a level 1 org unit. This means you cannot assume the level of the parent org unit - you have to actually look at what it's level is.

- Populating all ancestor Org Units in a multi-value field may be ok for group population but is not helpful for flowing values like "Division", "Branch", "Section" where you have to know the level.


Data feed from HR data source comes like this. For each Org Unit:

OrgUnitID: (Key, req) Identifier of the Org Unit

OrgUnitName: Name of the Org Unit

OrgUnitLevel: (Req) A number specifying level where 1 is the top. The lowest org unit number should not be enforced – current Aurion customer goes down to level 9. This will differ for different environments.

ParentID: Identifier of the parent in the hierarchy. It is *not* required that the parent level is one level up – eg., a level 4 can be the child of a level 2, skipping level 3. However we can assume there will only be one parent. The level 1 Org Unit will not have a parent.

Data to produce – for each Org Unit:

OrgUnitID: Identifier of the Org Unit

OrgUnitName: Name of the Org Unit

OrgUnitLevel: Level of the Org Unit

OrgUnit1: (Req) The OrgUnitID of the level 1 ancestor of this Org Unit

OrgUnit2: (If applicable) The OrgUnitID of the level 2 ancestor of this Org Unit

OrgUnit3: (If applicable) The OrgUnitID of the level 3 ancestor of this Org Unit

… OrgUnitN: (If applicable) The OrgUnitID of the level N ancestor of this Org Unit


Affected Versions:
Fixed by Version:

Answer

Answer
Declined

During a review of this topic for the purposes of determining a potential solution, we found that it is already possible to achieve this using the Join and PowerShell transformations currently implemented in Identity Broker v5.1.

The solution has been added to the documentation page Common Transformation Scenarios as an example of complex data manipulation using multiple transformations. Refer to that page for more details.

Under review

Thanks for raising this. I've linked back to this issue from the Data Modelling road map item.

Answer
Declined

During a review of this topic for the purposes of determining a potential solution, we found that it is already possible to achieve this using the Join and PowerShell transformations currently implemented in Identity Broker v5.1.

The solution has been added to the documentation page Common Transformation Scenarios as an example of complex data manipulation using multiple transformations. Refer to that page for more details.