TRIGGERcmd

Run commands on your own Windows, Mac, Linux, and Raspberry Pi computers from a flow through the TRIGGERcmd agent. Agents reach machines that sit outside any API, with the command set fixed in advance.

5 actions API key available

TRIGGERcmd website ↗ Platform Documentation ↗ Capability data verified 2026-08-01

The close checklist reaches the step that runs on the on-premise reporting machine

Agent calls List Commands to confirm the named command is still registered on that computer

Agent calls Run Command And Get Result against the registered export routine

Agent reads the row count the command reported back in its reply text

Agent compares that count against the source system before publishing the export

Agent posts the outcome and the computer name into the finance operations channel

An operator approves the restart command on the production machine when the export reports a failure

What This Integration Enables

Every automation platform eventually meets the machine that has no API. The lab PC that drives an instrument. The Raspberry Pi at a remote site. The Windows box that runs the one piece of software the business cannot replace. The usual answer is to give something in the cloud a shell on that machine, which solves the reachability problem by creating a much larger one, because now anything that can reach the automation can compose a command.

TRIGGERcmd inverts that arrangement, and the inversion is the entire reason to choose it. Commands are created and stored in the TRIGGERcmd agent on each computer by the person who owns the computer. A flow can only name one of them. The command text never leaves the machine, so there is no request in which an agent gets to decide what runs, only which of the already-approved things runs. That is a genuine security property rather than a policy you have to enforce yourself, and it is the property that makes it reasonable to put a machine like this inside an Orchestration as a Service layer at all. FlowRunner agents can discover what is runnable across every computer in the account, start a command and move on, start one and wait for its output to use in a later step, and press the buttons on a TRIGGERcmd panel that already carry their own saved parameters.

Without FlowRunner

Machines outside every automation The box in the corner runs its job when somebody walks over and clicks

Remote access for one command Reaching one machine means a VPN session and a remote desktop for a two-second task

Local output stays local Whatever the job printed sits in a log file on that machine and never reaches the workflow

With FlowRunner

Named commands called from a flow An agent starts a routine the machine's owner registered, by name, on the computer they registered it on

No shell to compose The command text lives on the computer and never leaves it, so a flow cannot assemble one

Output feeds the next step The command's reply comes back into the flow and the workflow branches on what it says

Use Case Scenarios

An on-premise step inside a cloud workflow

A month-end close runs across several cloud systems, but one extract has to happen on a server inside the building because that is where the source database lives. The agent calls List Commands to verify the export command is still registered on that computer, then calls Run Command And Get Result and waits. The command's reply carries the row count it wrote. The agent compares that count against the expected figure from the ERP, publishes the file if they agree, and raises an exception in the close checklist if they do not. Nobody remotes into the server, and the close does not stall waiting for the person who normally does.

Recovering a machine that stopped reporting

A monitoring check in Sentry or an alert from PagerDuty says a site machine has stopped sending data. The agent calls List Commands to see what recovery routines that computer's owner registered, finds the one that restarts the collector service, and gathers context: the last successful report, the alert history, the computer name. It does not run it. It presents the option to the on-call operator with everything needed to decide, and runs the command on approval, then reports what came back.

A panel button as a shared operational shortcut

A team keeps a set of frequently used routines on a TRIGGERcmd panel, each button carrying its own default parameters. The agent calls List Panel Buttons to discover the valid panel and button names, then wires the common ones into a Slack workflow so the team can fire them from where they already work. Press Panel Button runs the command that button is wired to, with the parameters the owner saved on it, so the shortcut behaves identically whether a person presses it from their phone or an agent presses it from a flow.

Human-in-Loop Highlight

There is exactly one part of a TRIGGERcmd call that did not come from the machine's own registry, and that is the Parameters field. Everything else, the computer, the command, the text that will actually execute, was fixed in advance by the person who owns the box. The parameter is the one free-text value in the request, it is passed to a command running on someone's production machine, and TRIGGERcmd's own guidance is to treat it as untrusted and avoid forwarding unvalidated data from earlier flow steps into it. So the parameter is what a person approves. When an agent wants to run a registered command with a parameter it derived from an inbound email, a form field or a chat message, it stops and puts the exact call in front of the operator: "Run backup-restore on FILESRV-02 with parameter 2026-07-31, sourced from the ticket body. Approve, edit the parameter, or cancel?" The operator sees the machine, the command name and the string that will reach it, and can correct the string rather than only voting yes or no. The same gate covers the recovery case, because restarting a service on a production machine drops whatever is running on it, and List Commands tells an agent what is runnable on that computer, never what is running on it right now.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via email

Human decides

Agent resumes with decision

Agent Capabilities

5 actions

Commands

Run Command Run a command already registered in the TRIGGERcmd agent on one of your computers, identified by its trigger name. Used for fire-and-forget operations such as waking a machine, starting a local script or kicking off a long job. Returns as soon as TRIGGERcmd accepts the request; only commands you registered yourself can be run, so this cannot execute arbitrary shell input.
Run Command And Get Result Run a pre-registered command and wait for the computer to report back what it produced, so the output can be used later in the flow. Used when the workflow needs to branch on a row count, a status string or a diagnostic result. The reply carries the command's output only when that command's Voice/MCP Reply field in the agent includes the result placeholder; otherwise TRIGGERcmd simply confirms the trigger was sent.
List Commands List every command registered across all computers in the account, including which computer each belongs to, its voice phrase, whether it accepts parameters and its icon. Used to discover valid computer and command names before calling Run Command, and to audit what is runnable on your machines.

Panels

Press Panel Button Press a button on one of your TRIGGERcmd panels, which runs the command that button is wired to with the default parameters already saved on it. Used to expose a frequently run routine as a single shared shortcut for both people and flows.
List Panel Buttons List every button across all panels in the account, with the panel each belongs to and the parameters saved on it. Used to discover valid panel and button names before calling Press Panel Button.

Frequently Asked Questions

What can FlowRunner do with TRIGGERcmd?

FlowRunner agents can run Run Command, Run Command And Get Result, and List Commands in TRIGGERcmd, plus 2 more actions.

Does connecting TRIGGERcmd to FlowRunner require OAuth?

No. TRIGGERcmd connects to FlowRunner with an API key, no OAuth flow required.

Can TRIGGERcmd trigger a FlowRunner workflow automatically?

TRIGGERcmd doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with TRIGGERcmd

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us