Provisioning

Description: HelloID Provisioning already supports the following targeted actions via the UI: - Re-enforce a granted entitlement (Business > Persons > Entitlements) - Update a single account / Update all accounts (Enforcement > Update accounts) - Unmanage an entitlement (Business > Persons > Entitlements) - Retry failed entitlement action None of these are accessible via the HelloID API. They can only be triggered manually through the UI. The gap: When a Service Automation workflow modifies Active Directory attributes (e.g. proxyAddresses, mail, userPrincipalName), those changes need to be propagated to downstream target systems via their Provisioning connectors. This cannot be automated because: 1. Enforcement only triggers on source system changes or business rule modifications — not on attribute changes made by Service Automation. 2. The UI actions above exist precisely for this purpose, but are UI-only. 3. Workarounds either introduce latency (waiting for the next scheduled enforcement) or bypass Provisioning entirely, losing audit trail and governance. Request: Expose the existing UI actions as API endpoints: POST /provisioning/persons/{PersonGuid}/entitlements/{EntitlementGuid}/re-enforce POST /provisioning/persons/{PersonGuid}/accounts/{AccountGuid}/update POST /provisioning/persons/{PersonGuid}/entitlements/{EntitlementGuid}/unmanage POST /provisioning/entitlement-actions/{ActionGuid}/retry No new behavior is needed — just programmatic access to what already exists in the UI, authenticated via API key and respecting existing thresholds and exclusions. A full enforcement is not a suitable alternative: it affects all persons and all target systems, introduces unnecessary load, and may trigger unintended changes across the entire tenant. Exposing these targeted actions via API would enable fully automated, end-to-end identity workflows while preserving the governance and audit trail that HelloID Provisioning provides.

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.

When resolving issues in the reconciliation report, it would be very helpful if the employee’s active contact details, such as contract information or at least the start and end dates, were displayed in the overview next to the account details. Having the employee’s contact information visible in the same view would provide administrators with all relevant information about the user in one place. This would make it easier to properly assess reconciliation issues without needing to look up the employee. Providing this additional context would improve efficiency when reviewing discrepancies and help ensure issues are evaluated and resolved more accurately.

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.

It would be useful if you could export all the custom fields. Obviously there must also be an import option.

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, 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.

Now for a specific connector, the supplier (Loket) changes the lifetime of the refresh token, and a refresh token can only be used three times. Therefore, it is necessary to update the refresh token each time an access token is requested. This means that we must have a place to store and update the refresh token to maintain continuous authorization. We could use a local disk or a remotely accessible disk, but we prefer a built-in solution in HelloID to store the refresh token. It must be possible to manually set the initial refresh token, and after each run, the refresh token should be updated.

Currently if you want to use the "Manager.ExternalId" under contracts in the source mapping, the ID of the Manager must match to the ExternalId of Person in the same source system. You cannot have it match against a manager in another source system. I'm requesting that ability to relate between the two. Example System A - Managers System B - Employees System B refers to the ID's of the managers of the employees on each contract. The ID then is checked against all persons for a matching ID. "System A" has manager "Johnny Doneszo SysA-12345" "System B" has employee "Jane Doe SysB-56789" Manager.ExternalId for Jane Doe would be set to "SysA-12345" which would connect to Johnny Doneszo

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.