What:
Add an aggregated view that shows Scripted Action runtime history for a selected scope, such as a Workspace or Host Pool, in a single table.
Value:
This would give administrators a practical way to see where automation is delivering value, how often it is succeeding, and what results it is producing across their environment. It would also give script authors a meaningful way to track the operational impact of the automations they build.
A major reason this would be valuable is that the current Insights > Costs & Efficiency > Administrator Time Savings can feel hard to defend in practical terms. It does not clearly answer questions such as:
- How was time saved?
- Where was time saved?
- What work was avoided?
- How is that being determined day to day?
This request is not meant to replace that feature, but it would provide one concrete, defensible operational lens into automation activity and its outcomes. That makes the value story much more real for admins, managers, and stakeholders.
How it should work:
An admin would select a scope such as a Workspace or Host Pool and see all Scripted Action executions within that scope in one view, instead of opening individual objects and reviewing tasks one by one.
Suggested columns:
- Workspace Name
- Host Pool Name
- Session Host Name
- Scripted Action Name
- Date
- Time
- Script Start Time
- Script End Time
- Duration
- Outcome
- Result
Outcome should clearly indicate Success or Failed.
Result should show the most relevant runtime output from the script.
Important requirement:
This feature becomes much more meaningful if the script itself can intentionally determine whether a task should be treated as successful or failed.
In other words, a script author should be able to write logic such that:
- if the script’s success criteria are met, the task is marked Success
- if the criteria are not met, the script can intentionally throw or otherwise return a failure condition so the task is marked Failed
That distinction matters a lot.
For reporting and value measurement, only Success outcomes should count.
Failed outcomes are still useful, but mainly for review and troubleshooting, especially when paired with a Result field that shows the script’s output. This is especially valuable in cases where the failure was intentionally produced by the script’s own logic, rather than caused by an Azure or Nerdio platform issue.
For example, a failed outcome caused by script logic is very different from failures such as:
- Nerdio pre-flight validation rejecting the script
- the script not conforming to required scripting behavior
- Azure/Nerdio being unable to install extensions on the target VM or session host
Those platform or delivery failures should not be confused with a script intentionally deciding that its success criteria were not met.
Example:
If I open a Workspace, I should be able to see all Scripted Action runs across all host pools and session hosts inside that Workspace, then filter the results to answer questions like:
- Which automations succeeded most often?
- Which hosts had the most failures?
- Which scripts are producing the most useful outcomes?
- Where is automation actually being used successfully?
Why this matters:
Today, task history exists, but it is difficult to turn that into a clear operational story across a broader scope. An aggregated view would make Scripted Actions far more useful for:
- validating automation outcomes
- spotting patterns across many hosts
- measuring repeatable operational benefit
- giving admins who author scripts a way to prove the value of what they built
Reporting use case:
This would also make it possible to export clean data to CSV or obtain it through API for daily, weekly, monthly, quarterly, or annual reporting on automation activity, reliability, and successful outcomes.
Related request:
This would become even more powerful if paired with a dedicated Result column in the Tasks view.
Comments (1 comment)