Enterprise Identity Plugins

The DingTalk, Feishu, and WeCom plugins connect enterprise directories, send personal application notifications, and provide enterprise single sign-on. Open an installed plugin under Integration → Apps.

Complete the provider setup first: DingTalk, Feishu, or WeCom. See Install Plugins for installation steps.

For a control-by-control explanation of organization, department, user, push configuration, and delivery log lists, see Enterprise Identity Plugin Lists And Actions, including search, export, binding states, dialogs, and a worked approval-notification example.

Choose The Features You Need

Feature	Soln entry	Changes the internal structure?
Fetch external organizations, departments, and users	Plugin → Organization Mapping → Fetch Directory	No; stores a directory snapshot
Bind existing objects	Organization Mapping → Bind / Automatic Binding	No; establishes identifier mappings
Update the internal structure from external data	Organization Mapping → Sync Organization Structure	Yes; requires separately enabling automatic synchronization
Send personal application messages	Plugin → Message Push → Push Configuration	No; uses bound, available members
Enterprise sign-in	Plugin → App Information, and Account Center → SSO	Sign-in does not create members or change their organization assignments

For notifications alone, bind the members. You do not need to enable structure synchronization or configure a group webhook robot.

Fetch The Directory

1. Enable the plugin and approve the provider API permissions and directory scope for the required departments and members
2. Open Organization Mapping and click Fetch Directory above the list
3. Review the Organizations, Departments, and Users lists. Fixed columns show names, IDs, and assignments; dynamic columns reflect fields actually returned by the provider
4. Click View for the details drawer. The download icon exports all rows matching the current search, including dynamic fields and bindings

After the first successful fetch, the tenant background service refreshes the directory approximately every five minutes, even with the page closed. The plugin and tenant services must remain running; rate limits and failed requests can delay updates.

API permissions, directory authorization scope, and application availability are separate settings. A successful sign-in or a single returned member does not prove access to the whole enterprise. Email and phone fields also depend on field permissions, member consent, and provider rules.

Bind Existing Objects

Manual Binding

Click Bind in the relevant list, select an existing Soln organization, department, or member, and save. Each object type has its own mappings. Within one plugin source and object type, external and internal objects have a one-to-one relationship.

Unbinding removes the relationship without deleting internal objects. After changing source identity settings such as Client ID, App ID, CorpId, or AgentId, recheck the directory, bindings, and notification settings for the current source.

Automatic Binding

1. Click Automatic Binding above the relevant list
2. Select a field on each side, for example external email and Soln member email
3. Choose an exact or case-insensitive comparison and save

Matching runs on save and after subsequent successful directory fetches. Only unbound objects with nonempty, unique values on both sides are bound. Resolve duplicates, empty values, and conflicts before matching again. Existing bindings, including manual adjustments, are preserved.

Automatic binding does not create objects or change assignments or permissions. Automatically adding a plugin member binding after enterprise sign-in is currently implemented for WeCom only; see WeCom sign-in and binding.

Synchronize The Organization Structure

Enable this only when external directory data should write to Soln.

1. Fetch the directory. Bind any corresponding internal objects first so they are not imported as new objects
2. Click Sync Organization Structure, to the left of Automatic Binding above the list
3. Configure field mappings: external source on the left, internal target on the right, such as an external department name to the internal department name (so_name)
4. Use the Auto Map menu to match by name or code, then review the results. This assists field configuration; it does not perform synchronization
5. Click Save Mappings at the bottom to retain the existing synchronization switch state. When initially disabled, saving alone does not enable it; click Enable Automatic Sync when ready. If already enabled, saved rules apply to subsequent runs

Internal codes use the so_ prefix, which code-based automatic mapping handles. Hierarchy and member assignments are resolved through provider relationships and object bindings, rather than writing an external department ID into an internal ID field.

Rule	Behavior
Number of sources	Only one external structure source can be enabled per tenant; enabling another valid source reports a conflict
Updates and creation	Bound objects are updated; unbound objects are created and bound. Only object types with configured field mappings participate
Schedule	Enabling schedules a directory fetch and synchronization, followed by approximately five-minute intervals; closing the page does not stop it
Validation	Internal required-field, format, option, uniqueness, and assignment checks apply; invalid objects are reported as failures
New members	Imported inactive and counted as pending activation. Administrators review and activate them within the seat limit; external activation does not automatically consume a Soln seat
Existing members	External disabling or departure deactivates members. Already inactive members are not automatically reactivated; protected initial members remain subject to internal guards
Member assignment	Organization is required; department is optional. Missing email, unresolved parent bindings, or an ambiguous primary department require correction
Disabling	Disable Automatic Sync stops subsequent structure writes and retains objects and bindings. Directory refresh and automatic binding are separate features

When An External Department Is Deleted

At the bottom of the dialog, choose Keep Internal Department (default), Disable Internal Department, or Delete Internal Department.

Missing bound departments are processed only after a successful complete fetch and confirmation that the plugin can read departments across the enterprise. Reduced scope, partial visibility, insufficient permissions, or a failed fetch are not treated as deletion. Reading the root department alone does not establish full authorization.

Deletion follows internal checks: child departments, assigned members including inactive members, business references, and permission references block deletion. History and audit records are retained. The initial department can be deleted once dependencies are resolved; the initial organization cannot. This setting handles missing external departments, rather than automatically deleting organizations or members that become temporarily invisible.

Review synchronization counts for created, updated, unchanged, pending activation, deleted, disabled, and failed objects, and open the failure records for the specific errors.

Configure Message Push

1. Enable personal application messaging on the provider and include recipients in the app's availability scope. DingTalk needs work notifications, Feishu needs an application bot, and WeCom needs a trusted IP
2. Under Organization Mapping → Users, bind each recipient to an available Soln member
3. Open Message Push → Push Configuration and use the add button beside the left menu
4. Select a business application; each application has one configuration. For DingTalk, also enter the AgentId of that internal application
5. Select allowed Message Templates in the multiselect. Empty means all messages for this application, including custom messages without a template. Selecting templates restricts delivery to those templates
6. Save, Enable the row, and generate a new business notification

Only new notifications entering that application's message center after enablement are forwarded; historical notifications are not backfilled. Approval templates send reminder cards and detail links. They do not create native DingTalk, Feishu, or WeCom approval instances or work tasks, or synchronize external approval decisions. Those integrations need a separately designed external-call and callback flow.

Generated-file and generated-ZIP notifications report the result and provide a viewing entry; they do not upload generated files as provider attachments. Custom messages must first enter the relevant business application's message center to participate in forwarding.

Logs And Retry

Open Message Push → Message Logs, filter by application, status, or time, and click View. The drawer shows the result, external recipient, and provider message or task ID.

Status	Meaning
Pending / Sending	Queued or being submitted
Accepted by provider	The provider accepted the request; DingTalk may only return an asynchronous task ID. This is not delivery or read confirmation
Awaiting retry	A background retry is scheduled
Failed / Skipped	Check the result, permissions, bindings, visibility, and push configuration
Uncertain	Provider processing cannot be confirmed; automatic retries stop to avoid duplicates

After correcting the cause, use the drawer's top-right retry action for failed or skipped records less than 24 hours old. The relevant push configuration must be enabled and still allow that message. Inspect the logs before generating repeated approval requests as a test.

Message Appearance

Provider	Current presentation
DingTalk	Native OA work notification with label/value fields. Header background comes from the message configuration, but DingTalk may replace the header text with the application name
Feishu	Application bot card with supported Markdown and text-color conversion; arbitrary custom header background colors are not sent
WeCom	Application text card using supported text styles; arbitrary header background colors are not sent

Provider limits on formatting, colors, buttons, and length prevent an exact reproduction of the Soln inbox. Feishu and WeCom use the configured header label, or the message title when absent; no fixed Soln heading is added.

Detail links open the corresponding Soln message or business page and require valid sign-in and business permissions. Receiving a notification does not grant access to the record.

Use Plugin Bindings In OpenLink

Open Integration → OpenLink → Subject Mapping, click Sync Plugin Bindings at the top, select an installed plugin, and save. OpenLink then uses that plugin's organization, department, and member mappings; the independent mapping configuration does not participate. Cancel the plugin binding to return to independent mapping.

This selects an identifier source without enabling structure synchronization. If the plugin is disabled, uninstalled, or its enterprise identity changes, resolve the unavailable source rather than substituting local IDs for platform IDs. The DingTalk organization root ID 1 and Feishu root ID 0 are mapping identifiers, not enterprise CorpId or tenant_key values.

Suggested Verification Order

1. Fetch the directory and bind one test member
2. Generate a new notification, then check the provider message and Soln log
3. Test workspace sign-in and the notification's detail link
4. Review existing-object bindings, field mappings, and seats before enabling structure synchronization