Auto-Provisioning WeCom Members from Jiandaoyun Onboarding: A Field-Proven Breakdown

What This Strategy Solves

When new employees are recorded in Jiandaoyun, they need an active WeCom (WeChat Work) account with an invitation sent right away. Doing it manually invites omissions; batch processing invites duplicates. If an employee doesn't receive the invite on day one, their badge, door access, and attendance all stall. We use the Qeasy Data Integration Platform to turn this into an observable, replayable strategy: once the onboarding form is submitted, a WeCom member appears within minutes.

Data Flow and Field Mapping

Data flows from Jiandaoyun (source), through the Qeasy middleware for cleansing and encoding, into WeCom's (target) member creation API.

Source: Jiandaoyun form /api/v2/app/{app_id}/entry/{entry_id}/data, POST query with pagination, up to 100 records per page. Target: WeCom /cgi-bin/user/create, POST to execute member creation.

Key field mapping table:

Two pitfalls: UserID has no source field, so Qeasy typically assembles it as "pinyin name + last 4 digits of mobile" to ensure uniqueness within the enterprise; the department ID is a string array and cannot be sent as a plain string.

How to Configure on Qeasy

Source component: Select the Jiandaoyun platform, mount the target app and form, choose POST + pagination, default page size is 10 — adjust to 100 as needed. Turn on idCheck and use _id as the dedup anchor to prevent the same onboarding entry from triggering repeatedly during polling.

Target component: Select the WeCom platform, endpoint /cgi-bin/user/create, method POST, idCheck on as well. The UserID field is assembled via a Qeasy expression rather than hard-coded in a source field — a common pattern among Qeasy customers: centralize encoding mapping so later department or staffing changes only need editing in one place.

Mapping layer: One-to-one mapping for name, mobile, and position; write an array→string conversion expression for the department field; assemble UserID in a Qeasy expression using the last four digits of the mobile number as the internal check digit.

Idempotency: Enable idCheck. The source uses _id and the target uses userid for bidirectional dedup, so even if the same record is re-polled, it only creates the member once.

Implementation Steps

Phased scheduling is key to this strategy — a common Qeasy customer pattern is "full-coverage fallback + real-time incremental" dual-track; here we focus only on incremental polling.

Phase 1 — initial full run: Manually trigger once to backfill existing employees who don't yet have WeCom accounts. Recommend adding a filter to only fetch records where "onboarding date ≤ today" AND "no WeCom member yet created," to avoid pre-boarding entries generating accounts prematurely.

Phase 2 — daily incremental: Schedule the source as */5 6-21 * * *, polling every 5 minutes; schedule the target as */6 6-21 * * *, offset by 1 minute to give Qeasy processing time. Both restricted to 6–21 because that matches the factory's admin working hours. Running at night when no HR entries come in is wasted quota.

Phase 3 — exception retry: Qeasy has a built-in failure replay mechanism. Network jitter or WeCom rate-limit failures will auto-retry in the next round; failures exceeding the threshold enter the alert queue for manual intervention.

Pitfall Review

First, UserID uniqueness. WeCom is strict about UserID — only digits, letters, -, _, @, . allowed, and the first character must be a digit or letter. We initially used pure pinyin names and found duplicate names collided directly. The safe approach is pinyin + last four mobile digits, which ensures uniqueness without exposing the full mobile number.

Second, department ID is an array. If the department field in Jiandaoyun is written as a string, it's sent to WeCom as a single department — the member appears to belong somewhere, but the org tree is wrong. Array-ification must happen at the Qeasy mapping layer.

Third, field reuse as number anchor. In the source material, _widget_1675653229901 (the name field) is simultaneously used as both number and name — a trap from the Jiandaoyun form design phase. On the Qeasy side, idCheck=true plus _id as a fallback keeps it safe; on the business side, recommend the customer create a dedicated "Onboarding Number" field in Jiandaoyun to eliminate field reuse.

Fourth, schedule window matching working hours. Both crontabs in the material are set to 6–21, matching this factory's actual working hours. Once a customer replicates this in a two- or three-shift factory, the window must be adjusted accordingly — otherwise night-shift onboarding entries don't get invites until the next morning, a poor experience.

Fifth, Jiandaoyun pagination cap of 100. The default source limit is 10. For factories with high onboarding volume, the default only fetches 10 records per poll, and every-5-minute polling can't drain a day's increment in time. Setting limit to 100 is safe practice, but watch for source-side API rate limits.

Suitable and Unsuitable Scenarios

Suitable: Onboarding happens in Jiandaoyun, collaboration happens in WeCom, daily onboarding volume is between tens and hundreds — small-to-medium factories or retail stores. Unsuitable: Scenarios requiring complex approval flows or frequently changing org structures in large enterprises — for those, connect directly to WeCom's HR module APIs rather than routing through Jiandaoyun. Also unsuitable when the source system isn't Jiandaoyun — the same strategy skeleton can be ported to other form systems, but field mapping and UserID assembly rules need to be rebuilt.