General

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.

Hello, i would like the name of the requester of a HelloID Support User to be included as Info in the eMail you get to approve the User. This way the recipient has a Name as Reference. And if it changes then maybe also take a look at this: https://feedback.helloid.com/general/p/comment-for-support-accounts

In https://feedback.helloid.com/general/p/allow-custom-return-path-for-dmarc-alignment a request has been made to enable DMARC alignment through a custom return path. The request has been closed with a "provider does not support multiple domains". However, DMARC alignment is becoming more and more a must have. Especially when things go awry when there are DNS failures. Legitimate emails would be rejected. If the current provider (mailjet) does not support multiple domains for return-paths, why not look for a provider that does?

It would be nice to be able to create more than one API key for different purposes, it is now limited to just one. We want to use one key for monitoring, one for reporting and possible other purposes.

In HelloID there is no availability of log files/audit files for changes a admin made in the system. In case there are more than one admin this is useful but specially for audits this is a need to have log files.

When the security rights are limited. The ability to read a product, person or application for example isn't possible. We are requesting the functionality to make a readable security settings. This allows to provide access to audit teams management teams helpdesk teams

As a user I would like to be able to query the active (purchased) licenses from the Elastic API (or general API) to be able to compare it with the active licenses in use to be able to generate an alarm.

Tags that are used in incidents are currently inconsistent for Access Management & Provisioning. This makes it hard to automate, because of a lack of standardisation. Mainly: Tags consist of a type, and a list Components. If you look at the tags for SA, the json looks like this: "tags":[{"type":"Domain","value":"SA"},{"type":"Component","value":"Tasks"},{"type":"Component","value":"Delegated Form"}]} This works the same for everything, except certificates. Those tags dont have a domain: "tags":[{"type":"AM","value":"Certificate"}] This is wrong, it SHOULD be: "tags":[{"type":"Domain","value":"AM"},{"type":"Component","value":"Certificate"] The other thing that should be fixed is that the provisioning tags are too generic. Based on the tags I can't see what part of provisioning has an error. SA has this granularity, because there are multiple Component tags so you can see the difference between a Delegated Form task, or a DataSource task. With provisionining there are only the components: 'Source' & 'Target' It SHOULD also have the components (for example): 'Aggregation', 'Threshold', 'Failed' If those are added you can see based on the tags what kind of incident there is. Failed Import, Import Blocked, Target theshold, Target failed, Aggregation Suggestion

From the July 2025 release we will deprecate the QR code login functionality. This means that QR code login can no longer be enabled on new tenants and tenants for which the QR code option is not enabled.

Adding an ID enables PSA ticketing applications to automatically close tickets.