Expose product request expiration date in $request variable for PowerShell tasks
planned
Remco Houthuijzen
When requesting a product in HelloID, it is possible to specify a expiration date for the request. However, this expiration date is currently not available in the $request variable within PowerShell tasks.
As a result, the selected expiration date of the request cannot be used during task execution, even though it is part of the request context.
Requested Enhancement
Expose the expiration date of the request in the $request variable so it can be accessed within PowerShell tasks.
This would allow administrators to use the selected expiration date in scripts, for example in notifications or conditional logic within request workflows.
Example Scenario
A requester submits a request for temporary access to an application and specifies a expiration date during the request process. As part of the workflow, the service desk is informed via email or a Topdesk ticket.
If the request expiration date were available in the $request variable, it could be included in the notification or ticket to clearly communicate until when the requested access should remain active.
Business Value
This improvement would increase the usability of expiration dates within request workflows, improve communication towards service desk teams, and provide more flexibility in PowerShell-based task automation.
Twan Duvigneau
It is also really usefull for the membertimetolive parameter in active directory, a few months ago i made a function for this that actually retrieves the value from the elastic log, really usefull.
M
Michiel van der Veeken
Twan Duvigneau: Thank you for your contribultion to this feature request. Please be aware that it is not considered best practice to set a Time To Live (TTL) or end date in external systems for accounts or permissions managed by HelloID. Doing so can result in unwanted behavior or confusion.
For example, an external system may automatically remove a group membership when the configured end date is reached, while the Service Automation product assignment receives an updated expiration date as part of a recertification process. This can lead to inconsistencies between HelloID and the connected system, making the actual state of access difficult to interpret or troubleshoot.
Twan Duvigneau
Michiel van der Veeken it depends on the product and wish, in this usecase we were publishing some pam forms that give access for 8 hours. They dont have a usecase for recertification. TTL's have another major advantage when you have multiple forms that can give access to the same group. Form a could give me access for 1 day, while form b could give it for 10 days. If i did not use a ttl the user would love the permission after 1 day because of the return action, if i use a ttl i get the result i want. Settings a ttl also removes an additional action, less actions is less logic to break, so its more reliable.
So its always usage dependant
M
Michiel van der Veeken
Twan Duvigneau: Thank you for the clarification. A lot indeed depends on the specific use case. Since this is a public feedback portal, we find it important to provide this nuance and context. Thanks again for your contribution and additional explanation.
M
Michiel van der Veeken
updated the status to
planned
Planned for 2026.09