Service Automation

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.

Provide the ability to setup more than one manager. Keep the existing manager attribute as the "primary manager" and have additional attribute for 1 or more managers.

To simplify form management, it would be useful if you could easily moving a control between steps on a multistep form. Right now you have to either copy the manually adjust the json using the editor or delete and recreate the control

We would like to have the ability to select a file via a file picker for end users looking to complete bulk import/processing via a form.

Add an option to the task schedules to schedule tasks monthly. Including specifying which day of the month and may stuff like "third tuesday" or such. Also with a selection of which months to include so we can do e.g. quarterly schedules.

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.

Currently Email sends are not in PowerShell scheduled tasks. Audit logging is not currently supported in PowerShell scheduled tasks. Whitin delegated forms they both work in the same way'

We request the ability to install the HelloID Service Automation Portal as an app within Microsoft Teams. This integration would allow end users to request access to specific products directly from the Teams interface and enable managers to approve or deny these requests within Teams. Additionally, we would like Teams notifications for both managers and employees about request statuses. Use Case: With this integration, end users can submit access requests to products directly within Teams. Managers receive notifications in Teams when a new request requires their approval and can approve or deny requests directly in the app. Once a request is processed, employees receive a notification in Teams informing them if their request has been approved or denied. This feature simplifies and centralizes the request process and keeps all involved parties informed without needing to switch platforms. Benefits: Increased User Accessibility: Users can make and track requests directly within Teams, reducing the need to navigate to other applications. Streamlined Approval Process: Managers are notified in Teams of pending approvals, allowing for faster, more convenient decision-making. Improved Communication: Automated Teams notifications keep employees updated on the status of their requests, reducing uncertainty and improving satisfaction. Enhanced Productivity: The integrated Teams workflow minimizes platform switching, enhancing efficiency for both users and managers.

Current Situation Currently, it is not possible to link an existing PowerShell script (from Automation) to a Product task action. Because of this limitation, you must copy and paste the script into each product individually. Why is this an issue? For auditing purposes, we want to make changes in TOPdesk (our ITSM platform) via their API. However, adding a separate script for each product is inefficient. Additionally, when TOPdesk updates their API, we would need to update the script in every product manually, which is time-consuming. Workaround As a solution, we can use an Automated Action in TOPdesk that is triggered by a webhook URL with Invoke-RestMethod. This way, the actions (such as creating and closing changes) are executed directly within TOPdesk. Note: However, this workaround is not always possible for other products, so a permanent solution is really needed to address this issue properly.

Within many applications, there are multiple roles, each role with their own AD-group. At this moment we have to use a separate request forms for each role. As certain applications have sometimes more than 10 different roles, it is not a very nice way of working and it would mean we get many request forms for 1 application. We would like to have 1 request form for 1 application in which you can select the wanted role. Based on that, the correct AD group is automatically assigned.