Service Automation

Description: Currently, HelloID Service Automation supports only a single-level category structure for organizing services. To enhance scalability and improve the user experience, we propose the implementation of a two-level (nested) category system. This would allow administrators to define subcategories within a main category, enabling more granular classification of services. Example Use Case: Main Category: Application Subcategories: Location, Functionality, Sub-Organization This structure would allow end users to more easily navigate and locate services relevant to their context, especially in environments with a large number of services. Requested Functionality: Ability to define subcategories within existing categories. UI enhancements to display nested categories clearly (e.g., expandable lists or dropdowns). Filtering and search capabilities that respect both category levels. API support for managing and retrieving nested categories. Benefits: Improved service discoverability for end users. Better organization and scalability for large service catalogs. Enhanced flexibility for administrators managing complex service structures.

Note: this feature is part of the milestone "Recertification" and requires the HelloID Governance module license. Product assignments that have the multiple assignment or conflicting products reason are not able to be approved or denied for recertification at this moment. For these types of reasons we need an other type of UI in order to select which product assignment you want to approve or deny. We need additional options in de Recertification approve/ deny UI where you can select one of the affected requests to be approved and the others will be denied. Also you need to able to specify which return actions should be triggered of the denied requests. This feature will add new functionality to recertifications, but still has some limitations. To manage this, we will implement a feature flag until a minimally functional set of capabilities is fully released. This approach ensures proper handling of recertification requests including administrative override functionality.

The general-incidents index only contains info on SA tasks that failed, not tasks that succeeded (unlike entitlement actions that do contain records on succeeded or failed attempts). It would be nice to add more info on SA task results, to be able to query this info for generating health reports on the environment.

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 have more options within the date & time form element. What we are specifically looking for is a option so the user can only choose dates from 5 days in the future. For example: Today it's the 21st and the next available date that the user can choose is the 26th or later.

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.

As an administrator I would like to have the option to return referencedata in a returnobject from scripts. In some cases you create a resource in a target system with a powershell script. The creation command of this resource returns a identifier. It would be nice to be able to store this identifier in HelloID so it can be used when returning the product. This makes it possible to return resources in systems where you don't have influence on the name or number of the product created. Also when having a referenceobject you can make sure you don't remove items which aren't created by the create actions. For example you have a product which results in a shared mailbox. After the product has been created some administrator renamed the mailbox manually which otherwise will cause the return script to go into an error state since the resource cant be found. If we have the objectID in an object to be used in the returnscript the script will execute succesfully.

In some environments, like ours, users don't go through the normal active -> disabled -> deleted lifecycle. We just remove users from HelloID SA after their last day (technically, HelloID provisioning removes a group membership and this causes their SA profile to be removed from LDAP synchronization). It seems that user deletion doesn't cause their products to be returned. As deleted is the next step after disabled, I think it really should.

I would like to have a dynamic required flag for forms - then you don't need to duplicate the field if you want to have it dynamic. I would like options like they are for the conditional visibility

Many of our delegate forms have AD account search as the first step, which requires you to look up an account, click to select it and then click "Next" to proceed to the second page of the form. Would it be possible to simply confirm the user selection by double-clicking the account in the search results? If you used UMRA before, you know how practical this is, would be great to see it in HelloID too, thank you!