How so? Well, for two reasons:
- Batch only rebuilds rather than "on-the-fly" insertions; and
- Non-completion of a rebuild
Batch Only Rebuilds
Hierarchies are rebuilt by a batch process handled within the Task Planner. This rebuild iterates over every PERSON object in the data repository and re-evaluates the hierarchy location for each and every user which is fine for re-synchronisation of a hierarchy against the PERSON objects.
But if a new PERSON appears in the system, they won't inherit their birthright entitlements until the hierarchy is regenerated. If there are a large number of PERSON objects in the system, a hierarchy rebuild may take some considerable time and may be scheduled to only execute once a day! Hardly ideal.
Fortunately, the upcoming latest and greatest version of IGI is supposed to address this inadequacy and should support "on-the-fly" insertion of PERSON objects into any hierarchy (and not just the Organisational Unit Hierarchy).
Non-Completion of Rebuilds
- Insertion of a user into a hierarchy triggers the creation of an account as a result of a birthright entitlements attached to the hierarchy node; but the account creation throws an error because it attempts to re-use the Master UID of the user to create the account but an account with that ID already exists!
- Insertion of a user into a hierarchy triggers the addition of an entitlement to a user's account as a result of a birthright entitlement attached to the hierarchy node; but the user seems to already own two accounts for that service - something which should not be possible with IGI in the current version (v5.2.2) but seemingly IS possible under certain circumstances!
from pwdmanagement pw
left join person p on pw.person=p.id
where pw.person is not null
group by pw.pwdcfg,pw.person,p.code