Service Automation

The current POST /api/v1/datasource endpoint (documented at https://tools4ever.stoplight.io/docs/helloid/08b4e750c6f76-add-or-update-a-data-source ) does not support setting or retrieving the agent pool configuration for a datasource. Current behavior: POST /api/v1/datasource accepts agentPoolGUID and runInCloud in the request body without returning an error (HTTP 200/201), but the values are silently ignored and not persisted. GET /api/v1/datasource/named/{DataSourceName} and GET /api/v1/datasource/{DataSourceGUID} do not return agentPoolGUID. Investigation via browser devtools reveals that the HelloID UI uses an internal microservice endpoint ( https://service-automation-prod-we.helloid.cloud/service/datasource/api/datasource ) with Bearer token authentication to persist agent pool settings — this endpoint is not part of the public API and is not suitable for use in automation scripts. Expected behavior: POST /api/v1/datasource should persist agentPoolGUID and runInCloud when included in the request body. GET /api/v1/datasource/named/{DataSourceName} and GET /api/v1/datasource/{DataSourceGUID} should return agentPoolGUID and runInCloud in the response body. Use case: We manage HelloID Delegated Forms via automated createform.ps1 deployment scripts. After importing a form, a post-import.ps1 script should be able to configures the agent pool on PowerShell datasources — this is required for on-premises connectivity (e.g. Active Directory, Exchange). Without API support for agentPoolGUID, this step cannot be automated and requires manual configuration in the UI after every deployment. Requested additions to the response body: { "dataSourceGUID": "...", "name": "...", "agentPoolGUID": "2w3e4r5t-3h4b-5678-81d2-0o0b8v7c6x", "agentPoolName": "Tenant_Agent_Pool", "runInCloud": false }

Since the introduction of the Product Assignment API endpoints in the 2022.06 release, the Product Ownership API endpoints have been deprecated. As of the 2026.10 release, the Product Ownership API endpoints will reach End of Life (EOL). This means these endpoints will no longer be available and any integrations relying on them will cease to function. As an alternative, customers should migrate to the Product Assignment API endpoints, which provide the supported replacement functionality. Our analysis shows that only a limited number of customers are still using the deprecated Product Ownership API endpoints within HelloID. These customers will be contacted individually to discuss the required migration steps. For more information, please refer to the API documentation: HelloID API Documentation (Product Assignments section): https://apidocs.helloid.com/docs/helloid/

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.

In Self Service, products can be configured with approval workflows that use a Resource Owner approver. However, there is currently no central overview that shows products where a Resource Owner approval step is configured while no valid Resource Owner Group is available. This can occur when: No Resource Owner Group is configured for the product. A Resource Owner Group is configured but contains no members. In these situations, the issue is often only discovered after an end user submits a request. Depending on the configuration, the requester can manually report that no approver is available. To do this, the user must navigate to My Products, open the requested product, and review the Request Timeline to identify that no Resource Owner could be found. This process is difficult to discover for end users and places the responsibility for identifying configuration issues on the requester rather than on HelloID administrators. As a result, misconfigured products can remain unnoticed for a long period of time and may only be identified after failed or delayed requests. Proposed solution Add a new governance/reporting view within the Self Service section of the Manage Portal that identifies products with potentially invalid Resource Owner configurations. The overview should list products where: A Resource Owner approval step is present in the approval workflow. No Resource Owner Group is configured. The configured Resource Owner Group contains no members. Suggested location: Manage Portal → Self Service → 'Resource Owner Validation' (or similar) Additional enhancements Display warnings directly in the product configuration page when a Resource Owner approval step is configured but no valid Resource Owner Group is available. Provide proactive notifications or health-check alerts to HelloID administrators. Allow filtering and exporting the affected products. Business value Prevents approval issues before end users submit requests. Improves governance and configuration quality. Reduces support tickets and troubleshooting effort. Shifts issue detection from end users to administrators. Helps administrators proactively identify and resolve misconfigured products. Improves the overall Self Service user experience by preventing approval failures caused by missing Resource Owners.

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.

Since Windows Powershell 5.1 doens't get any feature updates anymore, and Powershell 7 has some notable performance improvements it would be nice to specify the powershell version with which we want to run datasource and delegated form scripts with. Also the helloid cloud agent only supports powershell 7, so it makes sense to also support this on a locally installed system. === Updated scope of this feature request === Applies to the local Service Automation Agent (PowerShell data sources, Delegated Form tasks and new Product actions) Adds a new Agent configuration setting to support PowerShell 7 The Agent can run Windows PowerShell 5.1 or PowerShell 7 not both. You need to setup an other Agent Pool with other agents to support both PowerShell versions) PowerShell 7 must be installed on the local system Default value remains Windows PowerShell, which is the current behavior

In HelloID, the default Admin role does not include all available permissions. As a result, newly created portals require manual role adjustments before an administrator can fully manage the environment. For a clearer and more intuitive out-of-the-box role configuration, update the default permission set for new HelloID portals, so that the Admin role includes all permissions available at the time of portal creation. This would align the Admin role with common expectations. In addition, other default roles could be reviewed and adjusted where necessary to ensure logical, consistent, and clearly differentiated permission boundaries across the role model. As this applies only to newly created portals, existing portals remain unchanged and there is no impact on customer-defined or customized roles.

Provide CRUD actions for workflow approvals via API. It would be beneficial to have the following actions available in the api Get Workflow (w/ Approvers) Create Workflow Update Workflow Delete Workflow

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.

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.