Service Automation

In order to show managed products in a form and edit corresponding Active Directory Groups/Entra groups, I would like to have an API call to retrieve managed products for a user.

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.

Make it possible to use the Provisioning Target Systems in Service Automation. With the same options as available in de Business Rules. Simply select.

When using the managed users functionality in HelloID, it is currently only possible to request one product at a time for a user. While this works functionally, it can be inefficient in scenarios where multiple products need to be requested for the same user. In many organizations, requesters such as managers or service desk employees are responsible for requesting access to several applications or services for a user. With the current functionality, each product must be requested separately, which increases the number of steps and makes the process more time-consuming. Requested Enhancement Introduce the ability to request multiple products at once for a managed user. This would allow requesters to select several products in a single request instead of submitting separate requests for each product. The request process should still follow the existing approval and workflow logic for each product. Example Scenario A manager or service desk employee needs to request access to several applications for a new employee. Instead of submitting multiple individual requests, the requester could select multiple products and submit them in a single action. Each product would still follow its configured approval workflow. Business Value This improvement would make the request process more efficient for managers and service desk employees, reduce repetitive actions when requesting multiple products, and improve the usability of the managed users functionality.

Introduce the ability to configure a delegated requester group on a product. Members of this group should be able to submit requests for that product through the Managed Products functionality. This would allow designated users to request access for other users without giving them approval permissions. The delegated requester should only be able to submit requests and should not be able to approve them. Currently, the resource owner group is responsible for managing and approving access for a product. However, in some scenarios it is desirable that certain users can submit requests for a product without being responsible for approving them. Requested Enhancement Allow administrators to configure a delegated requester group on a product. Members of this group should be able to submit requests for that product through Managed Products for other users. This permission should only allow submitting requests and should not grant approval rights. It is important to clearly distinguish this functionality from the resource owner group. Resource owners are responsible for managing and approving access to a product, while delegated requesters should only be able to submit requests for that product. This configuration should also be manageable through the HelloID API so that delegated requester assignments can be automated. Example Scenario A service desk team is responsible for submitting access requests for users. Instead of making the service desk part of the resource owner group, a delegated requester group could be configured on the product. Members of this group could then submit requests for users through Managed Products without being able to approve the requests. Business Value This improvement would provide more flexibility in request delegation and better reflect real organizational processes where certain teams, such as service desks, are responsible for submitting requests while product owners remain responsible for approvals. It also enables automation and integration through the HelloID API for managing delegated requester configurations.

It would be good to be able to let all e-mails be sent via the internal SMTP server i/o SendGrid. Thereby not needing to open up the mail gateway to allow e-mail from SendGrid with our own sender addresses.

In the reconsiliation report of the governance module only entitlements created by the provisioning module are seen as valid permission. Assignments created by the Service Automation should also be incorporated in the reconsiliation report to give an accurate report and find discrepancies.

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.

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.

Introduce the ability to configure a delegated requester for a user by assigning a group. Users who are members of this group should be able to submit requests on behalf of the configured user. This allows certain users to create requests for another user without giving them approval rights. The delegated requester should only be able to submit requests and not approve them. This functionality is similar to part of the behavior that managers currently have, where they can submit requests for their employees. Requested Enhancement Allow administrators to configure a delegated requester for a user by assigning a group. Members of this group should be able to submit requests on behalf of the configured user. The delegated requester should only have permission to submit requests and should not receive any approval permissions. It is important to clearly distinguish this functionality from delegated approvers. Delegated approver functionality allows someone to approve requests in addition to or on behalf of the manager. Delegated requester functionality would only allow someone to submit requests on behalf of another user. This configuration should also be manageable through the HelloID API so that delegated requester assignments can be automated or integrated with external systems. Example Scenario A common scenario is that the service desk submits access requests on behalf of users. For example, a service desk employee may request access to applications or resources for another employee. By configuring a delegated requester group for a user or department, service desk employees who are members of that group would be able to submit requests on behalf of the user without receiving approval permissions. Use Case / User Story As an administrator, I want to configure delegated requesters for a user so that designated users, such as service desk employees, can submit requests on behalf of that user without granting them approval rights. Business Value This functionality provides more flexibility in request delegation and better reflects real organizational processes where service desk employees, assistants, or coordinators often submit requests on behalf of others. It also ensures that request submission and approval responsibilities remain clearly separated.