Automation Skill Builder
All posts Home
All posts / Enterprise workflow case study
Product blog · Case study

From 1–2 weeks to 1 day: automating a 230-step enterprise approval workflow

A real enterprise reimbursement approval process — login, API queries, 4-branch conditional logic — recorded with natural language prompts and packaged into deterministic executables. No manual coding required.

230
Total recorded steps
10
Packaged executables
90m
AI recording time
1 day
Total delivery
vs 1–2 weeks traditional RPA

The workflow

This is a real enterprise reimbursement approval process running inside a desktop application (DingTalk). Each working day, a finance approver must review a batch of expense claims and take one of four actions based on a risk flag returned by an internal API:

Green / White — low risk, approve directly.
Yellow — medium risk, countersign back to the submitter.
Red + special approval — high risk but authorised, approve with annotation.
Red + non-special — high risk, countersign and return.

Before automation, a human approver had to stay in the loop for every single claim — searching by document number, reading the risk flag, clicking through 20–40 steps per document, entering annotations, and confirming. The number of documents in a batch varies daily.

How it was built

The workflow was broken into 10 independent segments, each recorded as a separate natural language prompt session with ASB. Every segment compiles into a parameterised executable (.exe) that accepts runtime inputs and produces verifiable outputs.

Workflow architecture — 10 segments, 230 steps
① App Login & Data Collection DingTalk launch · Auth · Copy list → keys.txt 35 steps ② Data Filtering run_code: extract doc numbers → CSV 8 steps ③ API Interface Query Risk API → extract flag + tip fields 7 steps Flag colour? from API result GREEN / WHITE ④a Approve Search · Click pass · Paste tip · Confirm 28 steps YELLOW ④b Countersign Get employeeId · Scan page · Tab nav 49 steps RED ④c-1 Validate Copy page · run_code → judge.txt 22 steps Special Non-special ④c-2a Special Pass Approve + risk annotation 17 steps ④c-2b Countersign + return 41 steps ④d Result Check & Re-init Detect failure · Write CSV status · Reset 14 steps ⑤ summary.exe — Orchestrator Iterates CSV · dispatches branch executables · collects results 9 steps · run_orchestration TOTAL 230 steps 90 min recording 1 day delivery 1–2 wks trad. RPA
1
App login & data collection
Launch DingTalk, authenticate, navigate to approval list, Ctrl+A copy full list to keys.txt
35 stepsGUI-heavy
2
Data filtering
Extract document numbers from raw clipboard text via run_code, output structured CSV
8 stepsLogic
3
API interface query
Call internal risk API per document, extract flag (colour) and tip (annotation text) fields
7 stepsAPI + Logic
4a
GREEN Approve action
Search document, click approve, paste API-returned annotation, confirm
28 stepsGUI
4b
YELLOW Countersign action
Extract submitter employee ID via hover + double-click, detect button position via run_code page scan, countersign with Tab-key navigation
49 stepsGUI + Logic
4c-1
RED Validation
Open document detail, copy full page text, use run_code to determine if special approval applies, write judge.txt
22 stepsGUI + Logic
4c-2a
RED Special pass
Approve with full risk annotation text from API response
17 stepsGUI
4c-2b
RED Non-special return
Extract employee ID, detect countersign button position, return with risk annotation via Tab navigation
41 stepsGUI + Logic
4d
Result check & re-init
Detect if document is still on detail page (failure signal), write status and timestamp to CSV, return to approval list
14 stepsGUI + Logic
∑
Summary orchestrator
Iterate CSV rows, dispatch to correct branch executable by flag value, collect results — all via run_orchestration
9 stepsOrchestration

Key techniques used

Several patterns emerged during recording that are worth documenting for anyone building similar enterprise desktop workflows:

⌨️
Ctrl+A copy instead of scrolling
DingTalk's approval list supports full-page text selection including off-screen rows. This avoids building a scroll-and-capture loop entirely — one keyboard shortcut replaces 20+ steps.
📋
Clipboard as the data bus
Chinese text input uses clipboard paste (Ctrl+V) rather than direct keystroke injection, which avoids encoding issues. All cross-step data passes through files or clipboard, not in-memory variables.
🔍
Page scan for dynamic button positions
The countersign button shifts position when a "Modify" button is present. A run_code step scans clipboard page text for the count of '修改', then clicks the correct coordinate.
⇥
Tab key navigation for variable-height fields
The annotation input box grows with content, making its "Confirm" button position unpredictable. Three Tab keypresses reliably reach the button regardless of content length.
🔒
KeyVault for sensitive parameters
Passwords are retrieved from ASB's KeyVault at runtime rather than embedded in the recording. The executable never contains credentials in plain text.
🪟
Fixed window size for coordinate stability
Every segment starts by resizing the application window to 1802×965. This eliminates coordinate drift across machines with different display scaling or DPI settings.

Why not just write a Python script?

This is the most common question from developers who see the workflow. For the API query and data filtering segments — yes, a Python script would work. But those account for roughly 50 of the 230 steps.

The honest answer

The remaining ~180 steps are GUI operations: window positioning, coordinate clicks, clipboard sequences, hover-triggered tooltips, and dynamic button detection. Writing reliable Playwright or PyAutoGUI code for a real enterprise desktop app — with variable load times, session timeouts, and layout shifts — is exactly what takes 1–2 weeks in traditional RPA development. Recording takes 90 minutes.

The run_code steps that do appear — flag detection, page scanning, result writing — are embedded inline within the recorded workflow, not as a separate scripting layer. The entire workflow compiles into executables that run without Python installed on the target machine.

Traditional RPA comparison

Dimension Traditional RPA (Blue Prism / UiPath) ASB recording
Initial development 1–2 weeks 1 day (90 min recording + testing)
UI change recovery Re-develop affected components (hours–days) Re-record affected segment (~20 min)
Runtime AI dependency None None — deterministic executable
Cloud dependency at runtime Varies by deployment Zero — runs fully offline
Skill required Certified RPA developer Process owner with natural language prompts
Reuse across assistants Vendor-locked Exposed as standard MCP tools (Claude, Cursor, Copilot)

What the recording session actually looks like

Each segment starts with a natural language prompt in Cursor or Claude — no special syntax, no IDE plugins beyond the ASB MCP server. A typical segment prompt reads like a step-by-step description of what a human would do:

Example (Yellow branch, simplified):
"Start recording. Wait 2 seconds, click the document search box at 1406,257, select all, paste document number from clipboard, press Enter, wait 10 seconds, click first result... hover over the submitter icon area, double-click the employee ID field to select it, copy to clipboard, assign as employeeId... use run_code to check if the page contains 2 instances of '修改' — if yes, click 835,936; otherwise click 767,936... stop recording, save as yellow_action.py, analyse parameters: code and tip."

ASB records every MCP tool call during the session, parameterises the values you specify, and packages the result into a standalone executable. The recorded script (yellow_action.py) is saved alongside the executable for future AI-assisted editing without re-recording from scratch.

Current status and next steps

This workflow is still in active development — the document above represents the prompt design phase, with testing and tuning accounting for the remainder of the 1-day delivery estimate. Remaining work includes:

  • Edge case handling for empty search results and session timeouts
  • Production coordinate calibration (test environment coordinates differ from production)
  • Scheduling integration via ASB's scheduled run mode
  • Audit log review with the compliance team

The core recording is complete. What remains is the same validation work any software delivery requires — not additional development.

Try it on your own workflow

ASB is free to start — 1,000 MCP calls per month, no credit card required. For a workflow of this scale (230 steps, batch processing), a paid tier is recommended. If you have an enterprise approval process, data export, or repetitive desktop task, the recording approach works the same way.

Download for Windows Try in browser