One Time Script Run

[tim104979]

At the moment we are using another RMM and we use Run on onboarding a lot

What it does is when a client gets onboarded into the rmm it runs a script one time (in our instance a custom anydesk client and reports the id back)

[ToddHebebrand]

Good ask, and worth splitting into its two halves, because one already exists:

Ad-hoc one-time runs exist today. POST /scripts/:id/execute takes a list of device ids and runs immediately — no automation or schedule object is created (triggerType: 'manual'). In the UI that's the Run Script action on a device's detail page, and the multi-device execute modal on the Scripts page.

"Run on onboarding" does not exist yet — and that's the actual feature here. There's currently no trigger point that fires a script exactly once when a device first enrolls. The execution primitive is already shared (executeScriptOnDevices()), so the work is a run-on-enrollment script reference on the org/site (or enrollment key) config plus a hook at first agent check-in — a well-bounded feature, not new plumbing.

Your AnyDesk example ("runs once and reports the id back") is a two-parter, and the second half is tracked separately: #2698 covers letting a script write values (like that AnyDesk id) back into device custom fields, and most of its plumbing exists too. The pair together gives you the full Tactical-style workflow.

Keeping this open as the tracker for the onboarding trigger.

[tim104979]

is it also possible to see the output of the scripts when the run as automation?
a little bit like this. This shows the latest run of the script with the output that we set inside of the script

[ToddHebebrand]

Different ask than the last round — and it turned out to be worth digging into, because it's not just a missing UI column.

Manual runs already show what you're describing: script execution history and the device history tab both surface stdout, because those paths write a script_executions row that gets filled in when the agent result comes back.

Automation-triggered script actions don't — and the output is actually being dropped, not just hidden. The automation runtime queues the command with a synthetic execution id (runId:deviceId:actionIndex) instead of a real execution row. When the result arrives, the handler that would normally save stdout tries to match that string against a UUID column, fails, and the error is swallowed into a server-side log. So today the script's output isn't stored anywhere retrievable. There's even a column that was clearly meant for it (automation_run_device_results.output), but it only ever receives the automation's own log lines, and the run-history panel doesn't render it anyway.

Filed as #3162 with the full file:line trail — the fix is to persist the real stdout for automation runs and render it in the run-history expanded panel, which lands exactly the inline latest-run output view you're pointing at. It's distinct from both the onboarding trigger tracked here and the custom-field feature in #2698.

Status: gap confirmed and tracked in #3162; this discussion stays the tracker for the run-on-onboarding feature.