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 first reduced repetitive manual work and improved consistency. As volume increased, its runtime and sensitivity to page loading and network conditions led me to move these two actions to APIs.
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
From 3 minutes of repetition to two API actions.
The same student-level task: add the advisor and class coordinator, then create the teaching-service group.
Current API workflow
2 sec / student
Two short operations instead of repeated page navigation.
- Advisor + coordinator
- ≈ 1 sec
- Teaching-service group
- ≈ 1 sec
How the workflow evolved
Manual handling
≈ 3 minFind the student’s session, identify the advisor and coordinator, add both, then configure the service group. Repeat for the next student.
Yingdao RPA
≈ 1 min 30 secA scripted sequence shortened execution and made repeated handling more consistent in my use. Page loading and network conditions could still interrupt the run.
API integration
≈ 2 sec totalAbout one second to add both staff members, plus about one second to create the service group. This removes repeated UI navigation from these two actions.
Approximate per-student processing times, based on my latest recollection of actual use—not a controlled benchmark. Time for supervision and exception handling is separate.
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.
One student. Two operations. About 2 seconds.
After identifying the student and the required people, the two API actions replace repeated screen navigation. Timings are estimates from my use.
Student & session
Identify the lesson, advisor and coordinator.
Add the two staff members
Add the advisor and coordinator to the lesson.
≈ 1 secondCreate the service group
Set up the student’s class-level support space.
≈ 1 secondConfiguration complete
Lesson staffing and teaching-service setup are in place.
Bring the records together. Keep identity stable.
The current consolidation links separate source facts to a shared ClassIn UID, with validation and history preserved.
Source records
ClassIn, WPS and booking snapshots.
Validate & link
Stable UID bindings and transactional delta writes.
A unified read view
Student profile and linked operational details.
Animated process illustration · no live business data
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.