RPA orchestration
I used Yingdao to organize Excel downloads and scheduling-record downloads into separate subflows, with Python for data processing.
Case 01 / Education operations
From repetitive admin to connected operations.
I automated scheduling tasks with RPA and Python, moved two actions to APIs, and maintained the workflows as the platform changed. I am now consolidating their data around a shared student identity.
01 / Human workflow
Start with the human work.
The work was not one click. Each lesson required the right people, the right session and the right support group.
- Identify the student’s advisor and class coordinator.
- Find the student’s lesson session and open it.
- Add the advisor and coordinator to that session.
- Bind the student to a teaching-service group: a class-level support space.
Repeated across a large workload, the navigation and checking mattered as much as the final click. My goal was to make this recurring work executable without repeating every screen interaction manually.
02 / Implementation
What I actually implemented.
A task-level workflow first, then reusable data handling—not just a recording of mouse clicks.
Python data preparation
For quota checking, the Python module uses pandas to normalize phone fields, match course/card types, apply quota overrides, count bookings and export over-limit results.
RPA-to-API migration
In October 2024, I migrated personnel assignment and teaching-service configuration to API integrations. Student entry in the separate booking system remained a distinct workflow.
Maintenance after delivery
After a major ClassIn update in June 2025, I reworked affected integrations. Related work included daily over-limit lesson checks and weekly usage resets.
Implementation example: quota checking combines visual workflow orchestration with structured Python data processing.
03 / Technical decisions
Why RPA first—and why APIs later?
RPA let me automate the existing workflow. Slow execution, network-sensitive interactions and increasing volume made repeated UI steps a poor fit for the next stage.
RPA: close to the existing workflow
- Useful when the operation is already available through a UI, including steps without a suitable integration.
- The cost: navigation, rendering and timing dependencies; slow or changed pages can interrupt a sequence.
API: less UI dependence, different responsibilities
- Calls express the required operation directly, rather than repeatedly navigating screens. Better suited to these high-volume steps.
- The cost: access/session handling, request/response validation and compatibility with platform changes. An API is not maintenance-free.
I changed the integration method for the repetitive steps, rather than claiming that every related workflow should use an API. The June 2025 update is a concrete example of the maintenance that remained.
04 / Impact
What improved—and what I can measure.
The most useful comparison is between the work a person performs and the time a robot runs. Those are different measures.
Manual · about 2 minutes
My recalled estimate for the described lesson-administration task: locate the session, identify the people and add them.
RPA · about 1 minute
Approximate robot runtime for the comparable task, not one minute of continuous staff attention.
API · not timed
Direct integration replaced repeated screen interactions for two tasks. A matched API timing benchmark was not recorded.
Retrospective estimates, not a controlled benchmark. Staff time saved depends on supervision and exception handling. Teaching-service binding was also automated, but not timed separately.
05 / System map
The wider system—not just two API calls.
Scheduling automation grew alongside onboarding, lesson monitoring, leave-related work and reminders. The next problem was connecting their data without mixing up people or deleting history.
Open full-size diagram ↗Scroll sideways on a small screen. Text explanation follows.
06 / Consolidation
One identity. Clear data ownership.
In the current consolidation work, the design goal is one usable student profile—not one oversized table and not a rewrite of every inherited service.
Anchor identity on ClassIn UID
Memberships, cards, WPS details, lesson participation and observations remain separate facts linked to a common account.
Bind once; surface conflicts
WPS records are linked only when the required identity and uniqueness checks pass. Changed or duplicate phone data does not silently reassign an existing UID.
Protect history and local decisions
Snapshot validation, transactional delta writes and explicit ownership keep source facts separate from local settings and processing results.
Verify before business cutover
Read-view checks, repeat-import checks and an actual backup/restore test support the data foundation. They do not prove that notifications or approvals are live.
As of October 2026: the unified data foundation and read views are delivered. UID-based monitoring comparison is next; notification, leave approval, registration and booking cutovers remain separate acceptance steps. Existing services continue to run.
The same delivery mindset, applied to conversations and voice.