Provisioning

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.

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.

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.

We use business rule export as a rudimentary backup, and also for generating some documentation in Confluence. Please add Description to business rule export so we can get that information as well. Or implement a proper import/export/backup mechanism for provisioning.

Summary Add support for limiting concurrent sessions/actions per target system within HelloID Service Automation, similar to the functionality already available within the Provisioning module. Problem Within HelloID Provisioning, it is possible to limit the number of concurrent sessions for a target system. This is currently not possible within Service Automation. This can cause concurrency issues for target systems or APIs where updating an account requires sending the complete account object, rather than only the permissions that have changed. For example, consider two Service Automation actions that are started at approximately the same time: 1. Action 1 retrieves the current account object. 2. Action 2 retrieves the same current account object. 3. Action 1 removes permission A in memory. 4. Action 2 removes permission B in memory. 5. Action 1 sends the complete modified account object to the target system. 6. Action 2 subsequently sends its complete modified account object. Because Action 2 retrieved the account before Action 1 completed its update, the object held by Action 2 does not contain the change made by Action 1. When Action 2 sends its update, the removal of permission A can therefore be overwritten (without any error message). Effectively, this creates a lost update of the permissions. Requested functionality Add an option to limit concurrent sessions/actions per target system (or person) in Service Automation. Ideally, this would work similarly to the existing concurrent session limitation within the Provisioning module. For example, a target system could be configured with: Maximum concurrent sessions: 1 When configured this way, Service Automation actions targeting the same system would be executed sequentially. A second action would wait until the first action has completed before starting its interaction with the target system. This ensures that the second action retrieves the latest account state, including any changes made by the previous action. Benefits This functionality would: • Prevent lost updates. • Make Service Automation safer for APIs that require complete objects for updates. • Support systems that have limited sessions available. • Make it easier to build reliable Service Automation connectors for systems that do not support PATCH-style updates.

I would be nice to be able to enrich an existing source system with information providing from an other system. Example : I would like to get the user's phone number from a telephone system. Today it is possible but we need to do this logical directly into the Source System PowerShell script (so it is not possible using out of the box source connector like AD). It would be nice to have a specific functionality for that.

When you go to “Notifications > Systems > Configure > Audit Logs,” you cannot search for notifications that refer to a specific person. The search is based on “Message,” which contains only the title of the notification created in the system.

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.

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.

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.