WeCom and Jiandao Integration Overview: Closing the Loop on Attendance Sync and HR Collaboration Across 11 Strategies

Scenario and Value

In one of our real delivery projects for a multi-site retail customer, HR had a recurring pain point that looked small but kept biting them. Employees punched in on WeCom every day, yet the attendance data had to be manually exported from the WeCom attendance console the next morning and pasted into a Jiandao form. Monthly roll-ups were even slower — usually landing around the 5th of the following month. On a new hire's first day, IT first filled out the Jiandao onboarding form, then logged into the WeCom admin console to create the account and assign a department. Whenever the department code was missed or mistyped, the new employee couldn't clock in for the entire first week. After offboarding, the WeCom account often lingered for several days before being cleaned up.

None of these problems were caused by any single system failing. The issue was that attendance, HR, and the corporate directory had no automated closed loop between them. For this integration we narrowed the goal down to three things: reliably syncing daily and monthly attendance data into Jiandao forms, turning onboarding records into WeCom members automatically, and triggering member deletion from offboarding records. After rollout, 11 strategies cover both the attendance archiving line and the HR onboarding/offboarding collaboration line.

Integration Architecture and Data Flow

The overall architecture is a typical bidirectional ETL topology: WeCom and Jiandao are both source and target at different times, with the integration platform handling scheduling, field mapping, code conversion, and exception retries in the middle.

WeCom → Jiandao (data archiving direction)

• Source: WeCom open interfaces, split into daily attendance and monthly attendance.
• Middle layer: pulls incremental data within a starttime / endtime window, renames fields, converts types, and normalizes time zones.
• Target: two Jiandao forms (daily attendance, monthly attendance), with idempotent writes keyed by date + employee acctid or month + employee acctid.

Jiandao → WeCom (HR collaboration direction)

• Source: Jiandao onboarding form (different entry_ids per company/department), Jiandao offboarding form.
• Middle layer: maps Jiandao department codes to WeCom department IDs, performs idempotency checks to avoid duplicates, and locates members by userid for deletion on the offboarding side.
• Target: WeCom member management APIs (/cgi-bin/user/create, /cgi-bin/user/delete).

On the customer site, the middle layer is delivered on the Qeasy (轻易云) data integration platform. All 11 strategies run on its visual orchestration. Credentials such as app_id and entry_id are placed exclusively in environment variables and a key management service — never written into any strategy document.

Interface Inventory

The 11 strategies have no hard dependencies and can run in parallel or staged. The recommended order is: daily/monthly attendance → new-hire provisioning → member deletion.

Implementation Essentials

Staged scheduling. We split the 11 strategies into three phases. Phase 1 covers the two WeCom-to-Jiandao attendance sync jobs — daily at 10:40 and monthly on the 1st at 13:13. Phase 2 covers the 8 Jiandao-to-WeCom new-hire strategies, running every 5–30 minutes between 06:00 and 21:00, with 1–2 minute staggering between companies/departments so the WeCom member API is never flooded. Phase 3 is the offboarding deletion, scheduled at 01:23 in the low-traffic window.

Incremental vs. full reload toggle. Daily and monthly jobs use starttime/endtime windows for incremental pulls; onboarding and offboarding use Jiandao's filter conditions to pick up unsynced records. A manual full-reload trigger is preserved for first-time backfill and for reconciliation repairs after a few weeks of steady-state operation.

Code mapping. Jiandao stores departments as custom codes while WeCom uses numeric department IDs. A mapping table must be maintained, split per company (i.e., per entry_id). We recommend hosting this table centrally rather than scattering it across every strategy — adding a new company or adjusting a department becomes a single edit. The classic mistake is hard-coding the mapping inside each strategy's script.

Exception retry and dead-letter handling. The WeCom member API has rate limits, and the attendance API occasionally returns empty payloads under network jitter. Both need tiered retries: attendance data retries 3 times before going to a dead-letter queue for next-day reconciliation; member creation failures roll back and notify HR to avoid "ghost employees" who exist in Jiandao but not in WeCom.

Data privacy. The attendance app secret, the Jiandao app_id, and the entry_id are all delivered through the configuration center, never embedded in strategy scripts. Logs mask phone numbers and ID card numbers.

Best Practices and Lessons Learned

1. Centralize code mappings. In an early project at a manufacturing customer, department code mappings were inlined inside every onboarding strategy, so opening a new subsidiary meant editing 8 places. After moving to Qeasy, we abstracted the mappings into a single shared configuration dataset that all 8 onboarding strategies reference — the first consolidation pass after onboarding to the platform.
2. Write header and body in two phases. Monthly attendance involves per-person per-day detail. Writing the whole month in one shot means a mid-flight failure forces the entire month to retransmit. We recommend two tables — "monthly summary" and "daily detail" — write the summary first, then patch the detail rows. The failure granularity drops from "a whole month" to "a single day".
3. One strategy per entity for onboarding. With 8 onboarding strategies mapped to different companies/departments, it is tempting to handle everything in one. The robust pattern is to split by entry_id, which both enables differentiated scheduling and prevents a form-structure change at one company from cascading into every channel.
4. Put deletion in its own phase. Offboarding deletion runs at night in phase 3 instead of being mixed with onboarding because it touches the live directory more sensitively. A standalone window makes it easier for on-duty engineers to watch the logs.
5. Pick idempotency keys close to the business. Daily uses date + acctid, monthly uses month + acctid, members use userid — all natural business keys. Don't take shortcuts with system-generated auto-increment IDs, or any rerun will produce duplicates.

When to Use Qeasy

If your scenario is bidirectional sync between WeCom and Jiandao-class SaaS apps, with multiple parallel strategies, code mapping, incremental/full reload toggles, exception retry, and credential hosting, the Qeasy (轻易云) data integration platform gives you a steadier landing than rolling your own ETL. The 11 strategies can be orchestrated on a single scheduling canvas, the department code mapping is held as a shared config referenced by multiple strategies, credentials are centralized in the key management service, sensitive fields are masked before being written to logs, and day-to-day operations are driven by a dashboard that surfaces failed tasks and retry counts.