Custom App Permissions Compared: DingTalk, WeCom, and Feishu
Compare scopes, identities, directory access, messaging, approvals, documents, and calendar permissions for custom apps on DingTalk, WeCom, and Feishu.
Choose WeCom, DingTalk, or Feishu from the organization and external relationships already used in daily work—not from the longest API list. A custom application can only reach people, departments, groups, messages, documents, approvals, calendars, and customers within the app identity, granted scopes, visibility, resource membership, and current platform rules.
Wavesteam maps the required business actions to current official capabilities and proves them in a test tenant before recommending a platform. The client supplies its organization, user groups, existing ecosystem, and business constraints; it should not have to interpret permission catalogs alone.
1. The three ecosystems have different natural centers
| Platform | Natural strength | Strong fit | Common misunderstanding |
|---|---|---|---|
| WeCom | Employee collaboration plus service relationships with WeChat customers | CRM, customer success, support, stores, internal apps | Internal app messages, group bots, and external-customer APIs are different products |
| DingTalk | Organization, approval, attendance, stores, supply chain, and operational execution | Chinese organizations already running work and approvals in DingTalk | A group webhook is not a user-authorized enterprise application |
| Feishu | Messaging cards, documents, calendar, meetings, and collaborative workflows | Knowledge work, project coordination, interactive approval and automation | App scope alone does not grant access to every document, group, or user |
For ordinary consumers outside these relationships, use an appropriate public product and consented notification channel instead of forcing an enterprise collaboration platform.
2. Permission is an intersection, not one switch
Effective access commonly depends on:
- the application type and identity;
- scopes approved by an administrator;
- the application's visible organization or user range;
- the acting user's own authority where user authorization is involved;
- membership or explicit sharing of the target group, document, calendar, or other resource;
- field-level or sensitive-data approval;
- tenant edition, interface version, quota, and product policy.
A successful token does not mean the application can read the whole company. Conversely, a broad scope should not be requested merely because it exists. Wavesteam defines the smallest task-based scope and tests allowed and denied cases.
3. Map tasks, data, and identity before implementation
For each task, record the triggering user, application or user identity, input and output data, target resource, read/write action, required approval, audit record, failure path, and fallback. Typical tasks include directory lookup, message delivery, interactive cards, approval initiation and status, document creation, calendar scheduling, group automation, and customer follow-up.
Distinguish tenant users from external contacts. A customer's WeChat relationship in WeCom does not make them an internal employee. A DingTalk or Feishu group may include external members with different app and resource access. Do not copy personal chats or unrestricted documents into a custom app without a defined purpose and authority.
4. Prove the difficult permissions in a sandbox tenant
Before full development, create representative departments, roles, external users, groups, documents, approval records, and deactivated accounts. Test:
- an authorized and unauthorized user reading the same object;
- an app outside the visible range;
- resource ownership and membership changes;
- employee transfer and departure;
- revoked consent and expired credentials;
- duplicate callbacks, retry, rate limit, and event order;
- administrator permission reduction after launch;
- export, deletion, and audit requirements.
Record request, response, token identity, scopes, tenant, resource, API version, and platform error. A screenshot of one successful message does not prove the permission model.
5. Design for platform change and exit
Keep business truth in the enterprise system where appropriate. Store stable internal identifiers and map platform IDs rather than making one platform's user or department model the only database key. Isolate APIs behind versioned adapters, monitor permission and token failures, and provide a manual queue when a platform is unavailable.
The client entity should own the tenant and production application, with Wavesteam working through delegated roles. Document scopes, administrators, secrets, callbacks, event subscriptions, data retention, subprocessors, and decommissioning. When switching platforms, export business records and audit history that the contract and APIs permit; chat, document, and platform-native workflow semantics may still need redesign.
The recommendation is evidence-based: choose WeCom when lawful customer-service relationships and WeChat integration dominate; DingTalk when the operating organization already runs there; Feishu when collaborative documents and interactive knowledge workflows dominate. If no ecosystem has established users and the task is a standalone customer product, build the appropriate web, mini-program, or app entry instead.
Platform capabilities, scope names, review flows, and data boundaries change over time. Verify the latest requirements in each developer console and API reference before implementation.