Organizations, projects, and operations

Managing teams, managing projects, and maintaining deployments each have their own entry points. Identify the kind of action first, then use the appropriate role; system administrators, organization administrators, and project administrators are different identities.

Choose the right entry point

For organization basics and deployment differences, see Organizations and projects. For Cloud plans, billing administrators, and usage, see Plans and usage.

Manage organization and project members

Organizations have Owner, Admin, and Member roles; Cloud also has Guest and Billing Admin. Projects have three roles: owner (OWNER), administrator (ADMIN), and member (MEMBER).

When adding project members, select multiple active members from the current organization and assign Admin or Member. People outside the organization must accept an invitation first; the project dialog no longer searches global accounts by email or phone number. See Invite members for the full steps.

Public projects are open only to active Owners, Admins, and Members in the current organization, with Admin or Member as the default role. Explicit project roles take precedence; Guests still require explicit membership, and Billing Admins do not participate in projects. Project owners can adjust the project type and default permissions in Project settings.

Organization Owners/Admins can govern projects but cannot open private content without an effective project role. Private deployment system administrators' global project directory also does not automatically grant content access. Cloud system administrators separately have global project governance and content access permissions.

Manage platform accounts

System administrators view and maintain global accounts in System settings → Users. They can search, create, edit, import in bulk, or delete accounts. An account's system identity is system administrator or regular user, managed separately from organization roles.

Bulk import supports .xlsx, .xls, and .csv. Fill in names, email addresses, and passwords using the template downloaded from the page. Import WeCom/WPS members through organization enterprise integrations to establish the correct enterprise identity bindings.

Organization member management does not change email addresses, passwords, or system identities, or delete global accounts. Before deleting an account or disabling an organization member, transfer the projects they own; an organization Owner must also transfer organization ownership first. See Members and roles for the rules.

Account creation in a private deployment is subject to the license's user limit. Disabling public registration only changes the registration entry; administrators cannot bypass the user limit when creating accounts.

Manage project API-Keys

Create and manage keys in the corresponding project's Project settings → API-Key:

• admin can manage that project's resources;
• asker is for limited-permission calls such as asking data questions.

Choose permissions for the intended use and keep keys secure. API-Keys belong to projects and are not organization roles or system administrator identities. See Web embedding for website integration and OpenAPI for programmatic access.

Adjust runtime parameters

System administrators open System settings → System. Each field saves separately: leave a numeric input after editing, or toggle a switch, to submit. Watch the current field's save status and error messages.

Common defaults are listed below; the current deployment settings take precedence:

Deployment login, SMTP, and SMS use environment variables; see Deployment authentication configuration. For connection pools and process counts, see Operations and capacity planning. These are not runtime parameters that can be updated live on this page.

Common issues