Service Automation

Automatically maintain a dynamic group for resource owners and managers
Current Behavior HelloID knows which users are resource owners or managers, but there is no way to automatically group these users. This means: Resource owners and managers must be manually added to a group or role before they can be given access to anything There is no standard, reusable way to reference "all resource owners" or "all managers" Administrators must build and maintain custom solutions to keep these groups up to date These custom solutions are not instant and add unnecessary maintenance overhead Why this is a problem Resource owners and managers need access to various HelloID features — such as processing recertification reports, reviewing managed products, or handling managed users — but they cannot get this access without a group to assign permissions to. Since HelloID already knows who these users are, manually maintaining these groups is redundant and error-prone. Suggested Improvement Automatically maintain a dynamic group that always contains the current set of resource owners, and a matching group for managers. These groups would: Stay up to date automatically as users become or cease to be resource owners/managers Be instantly available — no delays from scheduled tasks Be reusable across different HelloID features: recertification, managed products, managed users, and any future functionality that needs to target resource owners or managers Remove the need for administrators to build and maintain custom synchronization logic
0
Support agentPoolGUID and runInCloud in the public datasource API endpoint
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 }
0
Load More