Local Runner Usage
Use Local Runner when automations need a local browser, tenant network access, MFA handling, or visible execution.
Running Locally
When the runner is online, cases and workflows can be dispatched to the local machine. This is useful for Workday tenants behind private networks, MFA flows, and scenarios where users want to watch the browser.
Confirm Runner Online in the Dashboard or tray menu.
Open the case, suite, or BP workflow.
Choose the local run option.
Keep the machine awake while execution is running.
Review results in the Execution view after completion.
Troubleshooting
Most local runner issues are caused by network connectivity, stale runner processes, missing browser dependencies, MFA prompts, or environment credential problems.
Practical Tips
- Restart the runner from the tray menu if it appears offline.
- Verify the server URL and API key.
- Check that the selected environment can log in manually.
- If a browser remains open after cancellation, stop and start the runner.
Operational Practices
The runner uses the user machine as an execution surface. Keep the machine stable while workflows are running, especially for browser-visible automations.
Close unrelated browser windows when debugging a flaky run.
Avoid sleeping or locking the machine during active execution if the workflow needs visible interaction.
Use the tray menu to stop the runner before shutting down.
Review runner logs when the Dashboard status and tray status disagree.
When To Use Server Execution Instead
Use non-local execution for workflows that do not require customer-network access, visible browser control, local files, or user-specific MFA state.
Practical Tips
- Use Local Runner for Workday tenants behind private networks.
- Use Local Runner when MFA or device trust must happen on a user machine.
- Use server execution for stable API checks or generic browser work that does not depend on a local desktop.