Members & Permissions

LanSphere uses a two-layer permission system — “roles + resources”: roles decide what a member can do on the platform; resource permissions decide who can see and use a specific app or Knowledge Base. Together they keep team collaboration smooth while meeting government and enterprise requirements for least privilege and clear responsibility boundaries.

This article is for team Admins and Owners: the definitions and capability matrix of the four roles, resource-level permission rules, System Users management, Models configuration, API Extensions, and Language Settings.

Tip: The System Settings entry lives in the “Account” pop-up at the top of the left menu, covering System Users, Models, API Extensions, and Language Settings.

The Four Roles

The platform has four roles with increasing permissions:

• Viewer: Use published apps in the App Square and view tool lists; no creation entries for Workflows, Knowledge Bases, Agents, etc. For business people who only consume app results.
• Developer: Create and orchestrate apps and Knowledge Bases; save, publish, run, and access APIs; build from templates; browse the Plugin Store; create Custom Tools, MCP Services, and Snippets and delete the ones they created; view the System Users list (emails masked) and the Models list. For builders of apps and knowledge.
• Admin: Everything a Developer can do, plus publishing as a Lansenger AI Assistant and publishing as a component; installing and deleting plugins and configuring plugin API Key authorization; adding members (Viewers / Developers); managing model credentials and default models; deleting tools created by any user; creating Project Folders; exporting logs; deleting / rebuilding WebApps and deleting API keys. For the team’s technical leads.
• Owner: Everything an Admin can do, plus adding Admins, changing member roles, removing members, and transferring ownership. For the person ultimately responsible for the workspace.

Insufficient permissions prompts “You don’t have permission to perform this action. Please contact an Admin.”

Role Capability Matrix

Notes:

• Developers can browse the Plugin Store; installing and deleting plugins requires Admin or Owner; plugin API Key authorization configuration likewise requires Admin or Owner.
• In System Users management, Admins can add Viewers and Developers; only Owners can add Admins, change member roles, and remove members.
• Custom Tools / MCP Services / Snippets: Developers can delete the ones they created; Admins can delete tools created by any user.

Resource-Level Permissions

Beyond roles, apps and Knowledge Bases have resource-level permissions, with consistent rules:

• Only me by default: A newly created resource is visible and usable only to its creator.
• Open to selected members: In card more-actions → “Permissions,” open the resource to selected team members — multi-select and select-all supported.
• Owner rules: Resources you created or were authorized to are visible and editable; deleting a resource, publishing to Lansenger, and permission settings are limited to resources you created yourself.
• Transfer ownership: Operate in the “Permissions” pop-up; the transferee list shows only the Developer role and above; after the secondary confirmation, the original Owner loses all permissions while collaborators and visible scope stay unchanged.
• Apps / Knowledge Bases without permission are invisible in lists; directly visiting the details page redirects to 403.

For the full resource-permission rules and operations, see “App Management.”

System Users Management

Entry: Account → System Settings → “System Users.”

Member List

The member list shows each member’s role, status, and join time; the email field is masked in the front end to protect personal info.

Adding Members

1. On the “System Users” page, click add member.
2. Fill in the invitee’s email and pick a role for them.
3. Send the invitation; the invitee joins the platform after completing email verification.

Role-selection boundaries:

• Admins can add Viewers and Developers.
• Owners can additionally add Admins, change member roles, and remove members.

Role Assignment Suggestions

Assign roles on a “minimum sufficient” basis:

1. Start new members as Viewers; upgrade to Developer only after confirming they need creation capabilities beyond using published apps.
2. Keep Admin tight — grant it only to technical leads who maintain members, models, and plugins.
3. Keep Owner to very few people, responsible for final accountability and ownership transfer.

Review the member list regularly, promptly remove members who have changed roles or left, and keep permission boundaries clear.

Models

Entry: Account → System Settings → “Models.” The platform supports connecting major LLM providers.

Configuring Provider Credentials

1. Pick the target provider in “Models.”
2. Add a credential (API Key).
3. Enable the models you need — they become available platform-wide.

Management Capabilities

• Enable / disable models: Control each model’s platform-wide availability as needed.
• Default model settings: Set the system default chat model, Embedding Model, Rerank Model, etc. — Admin and Owner only. The Embedding and Rerank Models also serve Knowledge Bases; the default chat model affects the default choice in app orchestration.
• Load balancing: Configure multiple API Keys for the same model to spread call pressure.
• Timeout and retry: Configure timeout and retry parameters per model for more stable calls.

Note: Model credentials are sensitive — have them maintained only by Admins or Owners, and regularly review enablement status and actual usage.

API Extensions

Entry: Account → System Settings → “API Extensions.” Supports custom API extensions for the Developer role and above, used to connect platform capabilities with external systems.

Language Settings

Entry: Account → System Settings → “Language Settings.” Switch the platform interface language, effective per member preference.

Related Reading

• “App Management”: Full rules for resource permissions, ownership transfer, and Project Folders.
• “Plugins & MCP”: Plugin installation, deletion, and API Key authorization configuration.
• “SKILL”: The role-permission table for skills.