桌面自動化無法確認 Save 是否成功時的處理方法
When a desktop automation is unsure whether Save worked
桌面自動化觸發 Save 後若無法確認結果，應將流程記為「未知」，而非直接當作失敗或成功，以免重複建立記錄或遺失工作。只有「尚未提交」狀態可安全地自動重試；未知時應先以唯一參考值搜尋記錄，若搜尋失敗或結果含糊，則停止並交由人員檢查。若服務提供 API，可查詢是否支援冪等鍵；文章亦建議用測試記錄中斷 Save 後的流程，確認不會盲目再次提交。
A desktop workflow submits a form. The app pauses, then the window changes. Did the record save, or did the request fail?
That is an unknown outcome, and it deserves its own state in the workflow. Treating every uncertainty as a failure can create duplicate records. Treating it as success can silently lose work.
Model the result as three states
For a record-entry task, track:
- Not submitted: the workflow has not triggered Save.
- Confirmed: the app shows a reliable success signal, or the record can be found afterward.
- Unknown: Save was triggered, but the workflow did not get enough evidence to decide.
Only the first state is safe to submit again automatically. In the unknown state, stop and inspect before retrying.
Prefer an idempotent operation when one exists
If the service offers an API, ask whether it supports an idempotency key or a unique external reference. Repeating the same request with the same key can then return the original result instead of creating a second record. A desktop interface may not offer that guarantee, so do not assume that clicking Save twice is harmless.
Give the workflow a way to reconcile
A unique value can help the workflow check whether a submission already landed. For example, use an order reference or a task-specific label that the app can search. After an uncertain save, look for that reference before deciding whether to submit again. Keep the search narrow and avoid logging the full form if it contains personal or confidential data.
Make the fallback explicit
If the record is found, mark the step complete and continue. If it is absent and the app is responsive, a bounded retry may be reasonable. If the search itself fails or returns ambiguous results, stop and ask a person to review. Do not turn “I could not verify it” into “it did not happen.”
Test the uncertain path
Use a test record and interrupt the flow immediately after Save: close the dialog, delay the response, or make the confirmation hard to read. Then check that the workflow enters the unknown state and does not blindly submit a second time. This edge case is often more valuable than another successful happy-path run.
A reliable automation records what it knows, distinguishes that from what it merely assumes, and chooses a safe next step. That matters most around actions that create, send, delete, or charge something.
macro8n is a local-first desktop app for building visual workflows. These design ideas apply to any UI automation tool.
Disclosure: this article was generated with AI assistance for the macro8n account.
來源：DEV Community · dev.to