Provisioning

With the new Entitlement overview we can see all business rules belonging to an entitlement. I would like to have the option to directly remove all occurrences of the entitlement in all the business rules, especially for the entitlements no longer available in the target systems. I spend the entire morning clicking to remove all occurrences while there where only 31 entitlements to remove.

As an HelloID administrator it would be nice to have an integrated solution to generate a secure link to provide the user's password after creation. Something like : onetimesecret.com

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.

Allow an export option within Business rules editor. Where the rules are being built and the list of users isshown on the right side of the screen. Could this be exported for external validation in other systems? Many thanks in advance.

Currently, the CorrelationConfiguration is not available in the uniqueness check script through the ActionContext . Because of this, when performing uniqueness checks in correlation scenarios, the correlation values need to be manually defined in the uniqueness check script. Why this is a problem The same configuration effectively needs to be maintained in two places: The Correlation Configuration of the target system. The uniqueness check script. When correlation attributes are added or changed, the uniqueness check script must also be updated manually. This creates duplicate configuration and makes it easy to overlook one of the locations. If these configurations become inconsistent, uniqueness checks may behave incorrectly. For example, during a correlate scenario with a unique value without iteration, the uniqueness check may incorrectly detect the person's own account as a conflict. Suggested Improvement Make the CorrelationConfiguration available in uniqueness check scripts through the ActionContext . This would allow the uniqueness check script to dynamically use the configured correlation attributes instead of requiring them to be manually duplicated. This would: Prevent duplicate configuration. Reduce the risk of configuration inconsistencies. Make uniqueness check scripts more generic and reusable across connectors. Prevent issues when correlation attributes are changed without updating the uniqueness check script. In short: expose the CorrelationConfiguration through the ActionContext so uniqueness check scripts can use the configured correlation values directly.

Currently we can collect all provisioning audit logs from Elastic, but we miss the systemID in the document. This field is currently available in the "provisioning-source-import" bucket but love to also have this value in the "provisioning-audit" bucket. The systemName is present but can change over time, so this could be a problem when grouping incidents, or even lookup incidents for a given system. There is also a CorrelationID in this document, maybe these identifiers could be stored separately so these are actually usable for us to filter on, like the importID which seems to be in there.

Currently, Rule Mining analyzes all imported entitlements that are present in a target system. In practice, some entitlements should not be considered when creating Business Rules. Permissions may, for example, be outdated, intended for manual assignment, or otherwise irrelevant to business rules. Rule Mining can still identify patterns for these entitlements, causing them to appear in the Rule Mining report and adding unnecessary results to the analysis. We would like to introduce an exclusion list for entitlements in Rule Mining. Administrators should be able to select specific entitlements from a target system and exclude them from Rule Mining. Entitlements on this exclusion list should not be analyzed and should not appear as results in Rule Mining reports. This would: Reduce irrelevant results in Rule Mining reports. Allow administrators to focus the analysis on entitlements that are actually candidates for Business Rules. Prevent outdated or otherwise irrelevant entitlements from influencing the Rule Mining analysis. Make Rule Mining reports easier and faster to review.

Currently the toxic policies need to be configured based on exact combinations, this works for simpler issues, like an f3 and e3 license. But when the potential combinations increase for lets say E1, E3, E5 and F3 the configuration gets really complex because you need to define the combinations for each possible combination. It would be way easier to configure and maintain an understanding of the configured toxic policies if they are priority based. It would look like this: Toxic policy: E5 E3 E1 F3 If the person will retrieve the entitlement E3 and F3, it should go through the policy and select the highest priority entitlement, in this case E3 because its at place 3, not 1. If the person retrieved E5 and E1 the same applies, it should grant 4. E5 and not 2. E1, etc.

Lately, we see an increase of errors on the Active Directory target connector saying "A connection to the directory on which to process the request was unavailable. This is likely a transient condition." During bulk changes, it seems that HelloID now may start more than 20 sessions at once, which can cause these errors. Just like the option on the Powershell target connector, it would be nice to have an option to limit the number of concurrent sessions on this connector as well.

I recently have users where not all the notification emails where send. I can find this in the audit log. And one of these emails contained the password. And notifications are the only official way to get the password of a new created user. So please add a option to resend notifications.