Service Automation

Description Recertification campaigns are typically executed for groups of users based on predefined scopes. While this works well for periodic access reviews, there are scenarios where organizations need to perform a targeted access recertification for a single user. This is particularly relevant during identity lifecycle events such as when a user changes role, department, or manager. In these situations, it is important to verify whether the user’s currently assigned products and access rights are still appropriate for their new position. Currently, administrators must wait for the next recertification campaign or create a broader campaign scope to review the access of a single user. This can make it difficult to respond quickly to organizational changes and maintain a least privilege access model. Requested Enhancement Introduce the ability to start an access recertification process for an individual user. This should allow administrators to trigger a recertification manually, through the HelloID API, or automatically based on identity lifecycle changes such as manager, job title, role, or department changes. Once triggered, the assigned reviewer should be able to review and either approve or revoke the user’s currently assigned products and access rights. Use Case / User Story As an administrator, I want to trigger an access recertification for a specific user when their identity attributes change, such as their department, role, or manager, so that the responsible reviewer can verify whether the assigned products and permissions are still appropriate. Business Value This improvement supports least privilege access principles, enables access reviews based on identity lifecycle events, reduces the risk of users retaining unnecessary access after role changes, improves identity governance visibility, and allows organizations to perform targeted access reviews without running full recertification campaigns.

Currently, the GET /datasource/{DataSourceGUID} API endpoint does not return the agentPoolGUID field, even when an agent pool has been configured for that data source in the HelloID web interface. The POST /datasource endpoint does accept agentPoolGUID (allowing the value to be set), but without being able to read the current value back, it is impossible to: - Display the current agent pool assignment in tooling - Conditionally update only when a change is needed - Build fully idempotent post-import scripts Requested improvement: Include agentPoolGUID (and optionally agentPoolName) in the response body of: - GET /datasource/{DataSourceGUID} - GET /datasource/named/{DataSourceName} - GET /datasource/all Expected response addition: { "dataSourceGUID": "...", "name": "...", "agentPoolGUID": "a1b2c3d4-...", "agentPoolName": "PRODUCTION" } Use case: We manage HelloID Delegated Forms via automated createform.ps1 deployment scripts, followed by a post-import.ps1 that configures agent pools on all PowerShell data sources (required for on-premises Exchange connectivity). Because the current agent pool assignment is not returned by the API, our tooling cannot show the user the current state before prompting for a change, and cannot skip unnecessary API calls when the pool is already correct. This forces either blind overwrites on every run or a manual check in the UI — both of which break a clean automated workflow.

Currently, the POST /delegatedforms API endpoint supports Font Awesome icons via the useFaIcon and faIcon fields. However, it is not possible to set or upload a custom image icon for a Delegated Form through the API — this can only be done manually through the HelloID web interface. Requested improvement: Add API support for custom form icons, so that Delegated Forms can be fully configured via the API without requiring manual intervention in the UI. Suggested implementation options: Option A — Dedicated upload endpoint: POST /delegatedforms/{DelegatedFormGUID}/icon Content-Type: multipart/form-data Body: file (image/png or image/svg+xml) Returns the stored icon reference (URL or GUID). Option B — Base64 field on existing endpoint: Extend POST /delegatedforms with: { "customIconBase64": "<base64-encoded image>", "customIconMimeType": "image/png" } Suggested icon specs (aligned with current UI behavior): - Accepted formats: PNG, SVG - Recommended size: 64×64 px or scalable SVG - Max file size: 100 KB Use case: We manage multiple HelloID tenants and provision Delegated Forms fully via createform.ps1 scripts. Custom icons are part of the form's identity and user experience. Being unable to set them via the API forces an extra manual step after every (re-)import, which breaks our fully automated deployment pipeline.

Description Currently, an input text form field is often used to perform validation within HelloID forms. While this works functionally, the layout and capabilities of this field are not ideal when the goal is validation rather than user input. In many implementations, PowerShell is used to validate entered data and return the result to the form. However, the current approach has several limitations which make the user experience and implementation less optimal. The validation logic often requires the use of regular expressions. From the PowerShell output, only a single field can currently be used to display the result of the validation. This makes it difficult to provide clear and structured feedback to the user. Additionally, it is not possible to visually indicate the validation result, for example by showing a success or failure indicator using an icon or color difference. Requested Enhancement Introduce a dedicated form field type specifically designed for validation scenarios. This field should allow validation logic to be executed and provide clear feedback to the user about whether the entered value is valid. Ideally this validation field would allow visual feedback such as success or error indicators and provide more flexibility in returning validation results to the form. Example Scenario A common scenario is updating a username. When a user enters a new username in a form, the system should validate whether that username already exists in Active Directory. After entering the proposed username, the validation field could run a check against Active Directory and immediately show whether the username is available or already in use. If the username already exists, the form could show a clear warning message. If the username is available, the form could show a confirmation indicating that the value is valid. Reference Implementation An example where this type of validation is currently implemented using a text input field can be found here: https://github.com/Tools4everBV/HelloID-Conn-SA-Full-AD-AFAS-Update-UPN-Email Use Case / User Story As an administrator, I want to validate user input in a form and provide clear feedback to the user about whether the entered value is valid, so that incorrect or conflicting values can be prevented before the request is submitted. Business Value This improvement would make form validation easier to implement, improve the user experience when filling in forms, and provide more flexibility for administrators who use validation logic in PowerShell during request workflows.

Currently, we can only see the Product name in the default approval mails. We would like to be able to customize the content of the default approval mails. For this specific scenario we need to provide more information than just the product name. And yes, we could just edit the product name to include all the information, but that would result in a very long product name. An example of the desired extra content: "Upon approval, <requester> can manage the tasks for project X without further approval. There may be a cost associated with this." Perhaps just (optionally) adding the product description to the content of the approval mail would suffice.

Today, the Managed Users overview can be opened directly for a specific user via a unique URL. However, this requires the HelloID userID. In many integration scenarios with external software packages, the HelloID userID is not available, only the username is known. To make integrations easier and more flexible, we want to support opening the Managed Users Overview based on the username, in addition to the existing HelloID userID option.

Currently, in HelloID Service Automation, we have the option “Requesting User Should Approve” in an approval workflow. When enabled, the requester must approve their own request, even if they submitted it themselves. In most real-life scenarios, we disable this option to avoid an unnecessary extra approval step when the approver is also the requester. Current Behavior When “Requesting User Should Approve” is disabled: No approval email is sent (this works correctly) However, the approval request still appears inside HelloID: As a notification under the bell icon In the user Inbox This makes it look like an approval is still pending, even though no action is required. Why this is confusing From a workflow perspective, the approval step is skipped. But from a user interface perspective, users still see an approval request, which causes: Confusion for end users Extra questions and support requests Doubt about whether the workflow is configured correctly Reduced trust in notifications If something appears in the Inbox or notification bell, users expect it to require action. Suggested Improvement When “Requesting User Should Approve” is disabled, the approval request should not: Generate an email Appear in the dashboard notifications Appear in the Inbox In short: if no approval is required, no approval item should be visible anywhere in the UI.

It would be useful if we could retry a task with updated variables. Sometimes the task fails due to an expired API key, buggy script, etc. But in that case you can't just fix the underlying issue and retry, since variables are populated one time when the task is first run.

I would like the ability to modify the text and layout of the confirmation screen, and/or disable the confirmation screen entirely for a self‑service product.

I don't want anyone to add all groups to a user. I would like this button to turn off. Or give the person a popup when he selects more lets say 5 at the time.