Provisioning

As an administrator I'd like to register a comment on why a person is excluded. That way other administrators can see why a certain person is excluded. It might also become handy over time to review why a person was excluded in the past, since remembering every case a few months later might be easy in a small company, but in larger companies it might not.

Currently in the General tab of the Configure Rule screen it is not possible to change the order of Categories. It would be very helpful if there was an option to sort (or drag-n-drop re-order) the list of category values in the general tab.

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.

Currently, the AD Target Connector in HelloID only shows a generic error message such as: [Error] Failed to update account for 'Person', details: Failed to update account However, the internal logging contains much more detailed information, including the underlying (inner) exception. This technical detail is not visible in HelloID, which makes troubleshooting more time-consuming than necessary. Example 1 – AD account not found HelloID shows: [Error] Failed to update account for 'Person', details: Failed to update account Internal logging shows: System.Exception: Failed to update account ---> System.Exception: Unable to find AD account with guid guid The actual root cause (“Unable to find AD account with guid …”) is not visible in HelloID. Example 2 – Access denied HelloID shows: [Error] Failed to update account for 'Person', details: Failed to update account Internal logging shows: System.Exception: Failed to update account ---> System.Exception: Internal ad error ---> System.Exception: Access is denied. The real cause (“Access is denied.”) is not displayed in HelloID. Requested enhancement: Please expose the full exception chain or at least the most specific underlying error message in HelloID audit logs and task details This would significantly improve troubleshooting efficiency and reduce dependency on internal logging or support.

Right now a user needs admin access to HelloID and gets full access to the Provisioning console. We would like to be able to grant someone only access to persons and/or business rules only.

Currently we have no overview off all entitlements and in which business rules they are configured. This means if you want to replace an entitlement with another one you’ll have to export the business rules and search within Excel or another application for the entitlement. Check which business rules the entitlement belongs to and go to those business rules and replace the entitlement. This is a lot of work and ideally you should be able to do this in HelloID without an export or use of other tools. Therefore we would like to have an overview off all entitlements and which business rules it is configured in and the person which has that entitlement. In this overview we will also show if the entitlement still exist in the target system.

I would like the option to be able to choose to just unmanage entitlements when a person is removed in HelloID. Currently, the entitlements are always revoked. However, there are cases in which we do not want that. I.M.O. we shouldn't act on the account data at all the moment we no longer have the data from a person. No data = no actions. But as both situations are desired perhaps we could make this configurable per system

Currently when aggregating two persons the account(s) that is registered under the main person will remain active and the account(s) that are not registered under the main person will be unmanaged. This leaved unmanaged accounts in the target systems which is really not desired for any customer and hard to manage. We'd like these options to be configurable in the Person Aggregation configuration, for example see the attached screenshot. This will also be important for auditing purpose, as leaving unmanaged accounts is a problem.

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.

We introduce filtering capabilities like reconciliation, enabling filtering by specific person attributes, especially from rule mining calculations. Filters for system, permission type, and permission will also be available. The general search field supports searching by permission name, condition values, and persons. We consider performance during development, so specifications may change.