WeCom Member Deletion Sync Strategy Based on Jiandaoyun Roster

What This Strategy Solves

In one retail customer's setup, HR runs the offboarding workflow through a Jiandaoyun form, but WeCom account removal was still done manually by an administrator. After a month, accounts for offboarded employees lingered in the WeCom directory, breaking attendance archiving and raising compliance concerns. This strategy handles exactly one thing: treating the Jiandaoyun form as the single source of truth, and automatically calling the WeCom delete API whenever a member's status changes to "to be offboarded", closing the membership lifecycle loop.

Data Flow and Field Mapping

The pipeline is unidirectional: Jiandaoyun (source) → Qeasy Data Integration Platform (orchestration) → WeCom (target).

The source side is a Jiandaoyun form whose key fields are the employee's userid, the WeCom userid, the status, and the last-updated timestamp. The target side (WeCom) accepts a single parameter: userid, passed to /cgi-bin/user/delete.

A note from the field: we often see teams naively use "display name" as the userid. Names collide; WeCom userids do not. The robust pattern is to have HR maintain a dedicated WeCom userid column in the form, optionally populated via OCR or the WeCom API once, and let Qeasy pass it through verbatim.

How to Configure It in Qeasy

Source side (Jiandaoyun)

• API: POST /api/v2/app/{app_id}/entry/{entry_id}/data, type QUERY.
• Key inputs: appId points to the member-roster app; entryId points to the form; fields explicitly lists userid,status,updated_at; limit is 100.
• Schedule: 3 5 * * * (daily at 05:03), with updated_at > last_success_time as the incremental condition.
• Critical flags: idCheck=true, buildModel=false. The first ensures each record is addressable; the second prevents Qeasy from modelling the form schema into the integration.

Target side (WeCom)

• API: POST /cgi-bin/user/delete, type WebAPI / EXECUTE.
• Input: userid is bound to the source-side "WeCom userid" field.
• Response check: configure errcode as statusKey and 0 as the success value.
• Schedule: 23 1 * * *, intentionally placed 20 minutes after the source pull so the target always sees the freshest state.

Orchestration layer (Qeasy)

• Centralised ID mapping: userid is the cross-system hard key, so we maintain a single mapping table inside Qeasy. HR populates it on day-one onboarding to keep dirty source data out of the downstream.
• Retry policy: WeCom occasionally returns 60011 (network busy) or 60020 (name conflict). Qeasy retries three times with exponential backoff by default.
• Manual fallback: Records that still fail after retries are pushed into an "exception queue" so HR can review them in a separate Jiandaoyun table and either re-trigger the deletion or skip.

Implementation Steps

We split the rollout into four phases to keep things safe.

1. Credentials and access: collect the Jiandaoyun appId, entryId, and the WeCom contacts-management secret. Store them only in Qeasy's credential vault; never inline them in scripts.
2. One-shot full reconciliation: run a full pull from Jiandaoyun, cross-check the "active" and "to-offboard" subsets against the WeCom directory, and fill in missing userids. This step is the foundation of everything that follows.
3. Canary go-live: start with a single test employee in the "to-offboard" bucket, verify the WeCom account is actually gone, then lift the gate. Qeasy's canary switch can filter by employee-number prefix.
4. Dual full + incremental track: once the backlog is cleared, the source switches into incremental mode (updated_at filter) and the target deletes on schedule. After two weeks of stable operation, the manual fallback is downgraded to "alert only, do not block".

Pitfalls We Have Hit

1. Status is a Chinese-language enum; do not hard-code strings in Qeasy: one customer renamed "to-offboard" to "pending-offboard", and the source filter silently broke. We later standardised on status codes in the mapping table, with the Chinese label kept only for display.
2. userid is globally unique in WeCom, but Jiandaoyun allows duplicate form submissions: the same offboarded employee can produce two rows, both of which enter the delete pipeline; the second returns 60111 (account already gone). The safe approach is to add a deduplication step in Qeasy so only the latest row survives.
3. Deletion is irreversible, so disable auto-reclaim first: if WeCom is configured to "reclaim and re-invite the same name after deletion", you will see the user disappear and instantly reappear. The fix is to switch off the reclaim policy, perform the deletion, then handle the account pool separately.
4. Nightly schedules can collide with WeCom maintenance windows: the 01:23 run hit occasional 5xx hiccups. We moved the target ahead to 01:23 and the source to 05:03, which sits in WeCom's quiet hours.
5. Do not let the same source feed multiple delete strategies: when one form is referenced by several strategies, concurrent deletes can collide. We split "delete member" and "deactivate member" into separate strategies, each running its own increment.

Where This Fits and Where It Does Not

Good fit: HR runs the full offboarding flow inside Jiandaoyun, WeCom is the single IM and attendance tool, daily offboardings are in the 0–10 range, and the status field is a structured enum.

Not a good fit: relationships span multiple WeCom tenants, deletion must cascade across departments, the Jiandaoyun form lacks a strictly structured status field, or the delete action itself requires a two-stage approval. In those cases, upgrade to a "deactivate + human confirmation" soft-delete pattern instead of hard delete.