Local-Only Execution
Some Flow-Like nodes need capabilities that exist only on the machine running Flow-Like Desktop. These nodes are marked as local-only in the catalog and show a monitor badge on the Flow canvas.
Before a run, Flow-Like inspects every node in the Flow, including nodes inside layers. If any node is local-only, the pre-run result marks the complete Flow as requiring local execution. A single run is not divided between local and remote workers.
Capabilities that run locally
Section titled “Capabilities that run locally”The current Automation catalog contains the main local-only node families:
| Family | Examples | Why it needs the device |
|---|---|---|
| Browser | Open a browser, navigate, fill fields, extract page data, download files, and take screenshots | Controls a browser session on the runner |
| Computer | Inspect accessibility elements, focus windows, move the mouse, type, use the clipboard, and capture the display | Uses the active operating-system session |
| Vision | Find or click image templates, inspect pixels, and wait for a visual state | Reads the runner’s display |
| RPA | Locate targets, act, assert, retry, checkpoint, and collect diagnostics | Coordinates local UI interactions and recovery |
These catalog capabilities do not imply that every camera, microphone, USB device, GPU, or locally installed program is available. Check the documentation for the specific node you intend to use.
For a complete automation guide, see Desktop & Browser Automation.
Choose a compatible execution mode
Section titled “Choose a compatible execution mode”| Flow or Event setting | Compatible with local-only nodes? |
|---|---|
| Local Flow | Yes, from Flow-Like Desktop |
| Hybrid Flow | Yes when invoked locally; no for a remote invocation |
| Remote Flow | No |
| Local Event | Yes, while the Desktop event runner is available |
| Remote Event | No |
Hybrid means that the same Flow can run locally or remotely depending on the caller. It does not split one graph across both environments. If the graph contains a local-only node, invoke that Flow locally.
An online App can still run a compatible Flow locally from Desktop. Conversely, an offline App has no server-side invocation path. See Offline vs. Online for the storage and execution matrix.
Run from Desktop
Section titled “Run from Desktop”- Open the App and Flow in Flow-Like Desktop.
- Confirm that the Flow mode permits local execution.
- Configure any runtime variables required on this device.
- Start the Flow from its entry node, a quick action, or a local Event.
- Keep Desktop running for local scheduled or background Events.
Local execution identifies the host. The Flow can still call APIs, databases, models, and other network services when its nodes and the machine’s network policy allow them.
Automation approval and system permissions
Section titled “Automation approval and system permissions”Desktop checks the capabilities used by the resolved workflow before running it. Browser control, clipboard access, application launching, native input, screen capture, accessibility, and window management are separate capabilities. A browser workflow does not ask for desktop screen or accessibility access.
A manual run can be approved once or remembered for the Flow. A local Event can be approved for that Event so later API, chat, or scheduled triggers can run without a foreground prompt. Native execution checks approval for both manual and background runs.
Remembered approvals are stored by Desktop and belong to the current profile, App, and workflow revision. Changing the workflow requires another approval. Switching profiles while a dialog is open cancels that approval attempt.
Operating-system access is checked separately. The permission dialog rechecks when the app regains focus, offers a manual recheck, and resumes only when every required capability is available. Closing or cancelling the dialog cancels the pending request. On macOS, the permission belongs to the running executable; a different development build or signing identity may need its own grant.
The Check Automation Capability and Request Automation Capability nodes expose the same native checks to Flows. Their status output distinguishes granted access, capabilities with no separate permission prompt, denied access, unavailable backends, and unsupported operations.
Build reliable local automations
Section titled “Build reliable local automations”- Prefer browser selectors or accessibility elements over fixed coordinates.
- Resolve the intended browser page, window, and display before interacting.
- Wait for an observable state instead of relying only on fixed delays.
- Bound retries and verify the result after consequential actions.
- Keep runtime values, paths, and credentials specific to the target machine.
- Capture diagnostics without including passwords, tokens, or sensitive screen regions.
- Test again after application, operating-system, theme, or display-scaling changes.