Provisioning

We want an overview where we can see the hierarchy of the organization based on the imported departments. For each department i'd like to see who is the manager, which other properties we can find within that department, for example which titles are linked to that department (with counts of within department/total in organization). This could be done for all properties of the contract. This would give organizations a clear overview of how their organization is represented in data for HelloID, and would help with scoping business rules, understanding business rules etc.

For example, if you select department and title, rule mining will only give you suggestions for 1 department, 1 title, of 1 of both. It will never show you rules that for example are scoped by 5 departments. The fact that role mining does not do this makes the report lose a lot of its values, for bigger organizations (lets say more than 800 employees) i dont see a lot of value in the report without this.

I'd like to give this item some attention again, because this issue keeps growing for our costumers. Time based product assignments currently send out emails x time before the assignment is being returned. This causes a bit of panic and frustration for end users that need this product for their work, only to find out they cant extend it. I've also spoken to multiple functional application administrators at different costumers that have a hard time convincing management that extending a product is not possible in 2026. This hurts the adoption of the entire service automation module. What we'd like is an option to extend the assignment, which when pressed gives you the option to select a new expiry date/time when dynamic, or when fixed shows you 'extending product to {date/time}'. When pressing confirm it executes the approval workflow assigned to the product. If the product is extended no additional actions have to be executed, only the return date of the product should change.

In AFAS, a manager can delegate tasks in case of illness or absence. This is automatically switched on and off (for example, when someone reports sick). This information is also available in the connector to HelloID. It would be great if this information could be used to activate and deactivate delegation within HelloID as well, so that the employee only has to set it up once.

The current Reconciliation report is not really a report, but more of an issues/incidents list. The important stakeholders in the governance process don't use this information, the want reports showing mismatch percentages, percentages of unmanaged permissions, trends, counts. They want to see that month over month improvements are being made to reduce the amount of unmanaged permissions, they want to see their governed entitlements increasing. These reports are especially essential when you think about NIS2 and GDPR, they state that the responsibility of cybersecurity is placed at the organizations governing body, which means that we should be able to report to them with our Identity and Access Management governance status etc. The solution is currently build solely for IT, which is exactly what NIS2 is trying not to do.

When a system is dependent on another system, HelloID should first process and correlate the primary system. The resulting correlation and account-linking information should then be used when processing the dependent system. For correlation, HelloID should: Process and correlate the primary system first. Link the accounts in the primary system. Make the resulting correlation and account data available to the dependent system. Use this information when correlating accounts in the dependent system. The same logic should apply to Role Mining. Role Mining should respect these system dependencies and use the correlation results from the primary system when processing the dependent system. Implementation benefit During an implementation, this approach removes the need to import entitlements into the primary system solely for Role Mining purposes. Instead, the primary system can first be correlated, after which its correlation and account information can be used to process the dependent system and perform Role Mining. This simplifies the implementation process, reduces unnecessary entitlement imports in the primary system, and makes better use of the existing relationships between primary and dependent systems.

I'd like the ability to create a condition in Business Rules that allows a rule to be applied only when another Business Rule has already been applied to the same person. For example, some HR systems contain external users or interns who do not always require an account. In these cases, I can create a Business Rule for account provisioning that excludes external users. I can then create a separate Business Rule for exceptions, allowing specific external users who do require an account to be added manually. The challenge arises when I create a rule such as "Enable Accounts". This rule attempts to run for all users, including those who will never receive an account. As a result, many users appear in Actions with a status of "Waiting". To avoid this, I would need to create separate Business Rules for enabling accounts, assigning default rights, granting additional entitlements, and so on. This quickly increases the number of rules that need to be maintained. It also increases administrative complexity because any changes must be replicated across multiple Business Rules. By allowing a Business Rule to check whether a user has already been included in, or granted access through, another Business Rule, administrators could significantly reduce the number of required rules and the associated maintenance effort. This would simplify rule management, reduce administrative overhead, and prevent unnecessary pending actions for users who are not intended to receive accounts.

We want to be able to set up a priority based calculation on source systems for the Primary Contract calculation. For example if you have a HR source and a Planning source, you'd always want the Planning source to be secondary to the HR source. This is import for the aggregation between the 2 systems

When creating a snapshot of a target system, a Permission Entitlement import can complete with warnings. In that situation, reconciliation cannot be used successfully while the snapshot contains warnings. The warnings therefore need to be resolved and a new successful snapshot must be created before reconciliation can be properly tested or used. At the moment, however, a new snapshot cannot be started immediately. Administrators have to wait approximately one hour before another snapshot can be created. Why this is a problem During development and implementation, warnings are often caused by configuration changes, mapping issues, or data that still needs to be adjusted. After resolving the warning, it should be possible to immediately create a new snapshot and verify the fix. Instead, the one-hour cooldown interrupts the development and implementation process. This is especially problematic because the target system cannot simply be left with warnings when reconciliation is required. Multiple test iterations may be needed before the complete configuration works correctly, and every additional warning can introduce another one-hour delay. Suggested improvement Allow administrators to manually start a new snapshot immediately after a Permission Entitlement import completes with warnings. This would: Allow reconciliation to be tested again immediately after resolving warnings. Reduce unnecessary waiting time during development and implementation. Speed up troubleshooting and validation. Prevent repeated one-hour delays when multiple configuration adjustments are required. In short: if a Permission Entitlement import completes with warnings and reconciliation therefore cannot be used, administrators should be able to immediately create a new snapshot after fixing the warning.

Possibility to save the filter on the reconciliation report, so it's possible to re-use when a new report is created.