Service Automation

Currently, end users can see all available Self Service Products, even those they do not have access to. When attempting to request such a product, they receive a message like "You are not allowed to request this product." This leads to unnecessary clutter and confusion in the product overview. We would like to limit the visibility of products so that end users only see the groups/products they are actually allowed to request. This would significantly reduce the number of visible products and improve clarity. At the moment, the only workaround is to use categories to segment visibility, but this requires creating a separate category for each product, which is not scalable or maintainable. Suggested Improvement: Add a configuration option to hide products from users who do not have access. Make product visibility dynamically dependent on group membership or access rights. Benefit: Improves user experience by reducing confusion. Keeps the product overview clean and manageable. Reduces administrative overhead by eliminating the need for excessive category creation.

We would like to see a functionality added to an SA form that makes the “submit” button optional. We use an SA form to look up members or owners of a team, for example. It's not about sending a request and the “submit” button causes confusion for the end user

It would be nice to have some logging who changed the configuration of a PowerShell Script or JavaScript. By this way we can see who has changed the last configuration.

I would like to create an API key which has limited access within service automation. As far as I can see, that's currently not possible. I would like to either A) assign a role to an API key or B) create an API key which impersonates a specific user.

I would like to have an option to extend my Product that is nearing its return date. Case: When I request a product that has a time limit specified, upon receiving the mail that the product is about to be returned I would like the option to extend (or re-request) the time limit on the product. Currently I would need to return the product before being able to request it again

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.

We would like to see the option to enable a button when the product is out of stock. The button then serves as a way to notify the product owner. When the end-user clicks on it the product owner will receive an e-mail stating that the product is out of stock.

Currently approvers only receive an emailed notification once. Would like to see repeating reminders for when approval request are still open after x-number of days

Just like the request for provisioning, it would be good to have a version history of all parts of HelloID Service Automation that is restorable, like we had in IAM and UMRA.

Currently, in HelloID Service Automation, when a product has no (valid) approver or owner configured, the requester must manually click a button in the request details to report this. Current Behavior When a product has no approver/owner: HelloID detects this (otherwise the button would not be shown) The requester must manually report the missing owner via a button If the requester does not click this button, nothing happens As a result: Requests remain stuck without progress Administrators are not notified The issue is often only discovered later Why this is a problem * This process relies on manual action from the requester, which is often forgotten. This causes: Stuck requests Lack of visibility for beheer/servicedesk Delays in processing requests Unnecessary troubleshooting Since HelloID already detects the missing owner, requiring manual reporting is redundant. Suggested Improvement Primary: Automatically send a notification/email to a configurable address (e.g. servicedesk or functional beheer) when HelloID detects that a product has no approver at the moment a request is submitted. Secondary: Provide an option to configure or customize the content of this notification. In short: If HelloID detects a missing approver, it should automatically notify the appropriate team, without requiring manual input from the requester.