Provisioning

Problem: When cloning a product in HelloID Service Automation , the associated form is linked , not copied . This is by design according to the docs, but it's inconsistent with how Delegated Forms behave — where cloning creates a full copy. This often leads to confusion. If users want a true clone (with its own form), they have to: Open the original product Switch to the editor Copy the JSON of the form Paste it into the new product's editor This process is time-consuming, error-prone, and doesn't align with expectations — especially since customers more often clone products than standalone forms. Proposal: Clone Option Prompt: When cloning a product, present a choice: - Link existing form (current behavior) - Create a full copy of the form (new behavior) Consistent Behavior: Match the cloning behavior of Delegated Forms for a more intuitive experience. Benefits: Improved Consistency: Aligns logic across different parts of HelloID Time Savings: Avoids manual copy-pasting of form data More Control: Lets users choose what fits their workflow Better Usability: Reduces confusion, especially during implementation projects

We would like support for simple conditional statements (if/else) in notification messages to add some info depending on the source system data, like whether or not the employee receives a phone. The variable syntax ({{ }}) looks like Handlebars syntax but the Handlebars helper did not work ( {{#if Person.PrimaryContract.Custom.hardwareTelefoon}}✅{{else}}❌{{/if}}).

We want to control only a specific OU (and sub-OU's) with Persons in Active Directory. We want to exclude all our admin-accounts, rooms and other OU's. Otherwise we must always exclude those accounts.

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

I'd like to see that the Evaluation History would remember more than 15 records. In some situations it means that there is only history of one or two days. It would be nice to see history of the last week.

Could there be a way to have snapshots of Person Exclusions, in the same way as there is a snapshot for imports from source systems. Also for an audit on what changes, such as additions/removals with a log of who added/removed the user.

I'm encountering an issue at a client where I can't add all groups as entitlements to a business rule (built-in AD). The group in question has a name that consists of two characters. When I search for it, I get more than 500 results, but the group is not among the first 500. It seems that the list of entitlements doesn't expand beyond the first 500 results. In other words, I can't select the group to add it to the business rule. I've also tried searching by OU and using quotes around the search term, but unfortunately, neither option solves the problem. Could we add an option to extend the limit of 500 entitlements or add an option to filter on exact matches (maybe by default and add wildcard filters)?

When a configured toxic policy rule decides to deny an entitlement in favor of another entitlement, I would like to see that decision mentioned in the persons audit log. Otherwise it would be hard to see why a person should get an entitlement according to a business rule but does not get it.

Currently there is little information about aggregation suggestions available in Elastic - the general-incidents index shows in the 'identifier' field a record with 'PersonAggregationSuggestionAvailable' when there are ubsolved aggregation suggestions present. And the user actions on Aggregations are available in the provisioning-audit index. It would be nice to see more details on the persons (and number of persons) that it applies to including their CorrelationID. This type of info is available within the HelloID Provisioning environment, so hopefully it is possible to log it to elastic also? Perhaps this information should be present in the provisioning-audit index (with a relation to the correlationID of the applicable snapshot)

Within this feature we review the HelloID entitlement state agains the current state of a Powershell V2 target system. Match the state from a Powershell V2 system (network state) against entitlement state (based on account entitlement reference) Match only on granted entitlements (not on open actions) Based on mismatching show the following data in a report Filter on systems & scenario & mapped account properties. This should contain all the same specifications as the current reconciliation for Active Directory. The biggest differences are that we support subpermissions in the report but it's not possible to take actions (against the target system) on the subpermissions besides exclude or resolve.