Fit guide · workflow automation
Workflow automation without APIs: when browser, desktop, legacy software, and files all matter.
Many operational workflows are not API-shaped. They move from a browser portal to a spreadsheet, into a desktop or legacy application, and back to a system of record. The right approach is not to pretend every handoff is an integration. It is to use the strongest connection available at each step, keep the path reviewable, and stop when a check fails.
Short answer: APIs are preferred when they are reliable and expose the needed action. Browser, desktop, legacy-interface, and file steps can be evaluated when that is where the real work happens and the result can be verified.
The decision
API-based integration compared with UI automation for legacy systems.
Use an API when
- the required data or action is exposed;
- authentication and permissions are dependable;
- the response gives a clear success or failure state; and
- the API is more reliable than reproducing the user path.
Evaluate a browser or desktop path when
- the team already completes the work through a visible interface;
- the system has no suitable API or the API misses the needed step;
- the path includes files, approvals, or legacy software; and
- the intended result can be checked after the action.
Do not automate yet when
- the “right” result depends on undocumented judgment;
- the interface changes without a detectable signal;
- there is no safe way to keep a consequential change under human responsibility; or
- the team cannot define what completion means.
The operating model
One reviewed path across every system.
Map the real work
Start with one representative case from input to intended result. Document the tools, handoffs, checks, and exceptions that a process description usually leaves out.
Review the boundaries
Inspect the mapped steps. Keep approval, judgment, and sensitive actions outside automated scope unless a separate review mechanism is implemented and verified. Define what should happen when a record, file, or screen does not match expectations.
Pilot only the eligible cases
Choose a trigger during implementation, define how the intended result will be verified, and specify what context an exception must return before test volume begins.
The measurement
Measure the work returned, not just the run completed.
A fast run is not automatically a valuable run. Establish the manual baseline, then measure whether eligible cases complete without teammate handling and how much exception review remains.
Runtime, completion rate, review time, and cost per completed case should be reported separately. The workload examples on the main page are illustrative, not customer results. Use the workflow automation pilot scorecard for definitions and a downloadable template.
The boundary
No-API does not mean no controls.
- Human responsibility: keep consequential actions outside automated scope unless a separately verified review mechanism is part of the implementation.
- Observable completion: define the evidence that proves the intended result.
- Exception return: stop uncertain cases instead of guessing through a changed screen.
- Controlled pilot: increase volume only after completion, runtime, and cost meet the agreed bar.
Questions
Common no-API workflow questions.
Can workflow automation work without an API?
It can, when a pilot has a stable visible path through a browser, desktop application, legacy interface, or file-based system and a result the team can verify. An API is useful where it is reliable, but it is not required for every step.
When should a team use UI automation instead of an API?
Evaluate a UI path when the real work lives in a portal, installed application, legacy interface, or file that has no suitable API. Prefer an API when it exposes the needed data or action reliably and with better controls.
Is browser or desktop automation safe for consequential work?
A safe pilot needs a reviewed path, an observable success condition, and a defined human responsibility before consequential changes. Keep the action outside automated scope unless the implementation has a separately verified review mechanism. If the workflow cannot confirm the intended result, that case should stop.
How does API-based integration compare with UI automation for legacy systems?
Prefer an API when it exposes the needed data or action reliably and with better controls. Evaluate a UI path when the real work lives in a portal, installed application, legacy interface, or file that has no suitable API. Do not automate undocumented judgment or consequential changes without a defined human responsibility.
What should a no-API automation pilot measure?
Measure the manual baseline, eligible cases, verified completions without teammate handling, exception review time, runtime, and cost per completed case. Report team hours returned separately from elapsed runtime.
Apply the guide
Bring the workflow that keeps crossing the gap.
In 30 minutes, map the real tools, handoffs, checks, exceptions, and pilot fit. No process document required.