Service Automation

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.

When using the managed products functionality in HelloID, it is currently only possible to request a product for one user at a time. While this works functionally, it can be inefficient in scenarios where the same product needs to be requested for multiple users. Managed products are typically used by resource owners or product owners who are responsible for managing access to their applications or services. In situations where access needs to be granted to multiple users, the requester must currently submit a separate request for each individual user. Requested Enhancement Introduce the ability to select multiple users when requesting a product through the managed products functionality. This would allow a requester to select several users and submit the request in a single action instead of creating separate requests for each user. Each request should still follow the configured approval workflow for the product. Example Scenario A resource owner is responsible for managing access to a specific application. Several employees need access to this application. Instead of submitting separate requests for each user, the resource owner could select multiple users and submit the product request once. Business Value This improvement would make access management more efficient for resource owners, reduce repetitive actions when granting access to multiple users, and improve the usability of the managed products functionality.

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.

When configuring a product in HelloID, it is possible to define a return date. However, this return date is currently not available in the $request variable within PowerShell tasks. As a result, this information cannot be used during task execution, even though it is part of the request context. Requested Enhancement Expose the configured product return date in the $request variable so it can be accessed within PowerShell tasks. This would allow administrators to use the return date in scripts, for example in notifications or conditional logic within request workflows. Example Scenario A product is requested with a return date, for example temporary access to an application. As part of the request workflow, the service desk is informed via email or a Topdesk ticket. If the return date were available in the $request variable, it could be included in the notification or ticket to clearly communicate until when the access is valid. Business Value This improvement would increase the usability of the return date feature, enable better communication in notifications and service desk processes, and provide more flexibility in PowerShell-based workflows.

We often run into situations where we can't fit our approval logic into the system. Rather than having specific options for those I'd like the option to let a PowerShell script determine, based on user ID, product SKU etc, which approver is applicable.

I would to have the option to select a list view for Servicedesk form. The same as is possible with Products.

We’re adding audit logging for product request deletions to complete the visibility of the product request lifecycle. Currently, most product request lifecycle events are logged to Elastic, but deletions are not. This can lead to gaps in audit trails. Especially in scenarios where a user leaves the organization and their HelloID account (and associated product requests) are automatically removed. With this update, every deleted product request will be logged to Elastic, ensuring a complete and traceable audit history for compliance and investigation purposes.

We’re introducing a new filter mode option to grid filter components across the platform. Currently, selected filters (e.g., department or job title in the Managed Users overview) are stored in the browser URL. This allows users to easily save or share filtered views. However, when many filter values are selected, the URL can become too long and exceed browser limits. With this update, users can choose between two filter modes: Inclusive (default): show only the selected values Exclusive: show all values except the selected ones This makes it much more efficient to filter large datasets. For example, instead of selecting dozens of departments to include, you can simply exclude a few. Scope: Applies to grid filters in both the end-user and admin portal that include a search filter Adds URL support for the new filter mode Renames “Select All” to “Select Results” Disables the “Select Results” button when the search bar is not in use

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.