Collaboration Components

Collaboration Components consolidates reusable capabilities into components that any app on the platform can call. When the same business logic shows up in app after app, package it as a collaboration component maintained in one place, and let every app call it directly — no repeated building. This article introduces the three tabs of Collaboration Components in LanSphere and how to create, edit, publish, set permissions on, and call Snippets. It is for developers who build and maintain shared capabilities.

Note: The “Collaboration Components” entry is visible only to the Developer role and above.

Why Collaboration Components

When a team builds apps, the same situation keeps coming up: multiple apps all need to do the same thing — format query results into a standard notification, run the same data-validation logic. If every app builds its own copy, it not only wastes effort but also means updating every app one by one when business rules change, and consistency easily drifts.

Collaboration Components is designed to solve exactly this: package such common logic as a component and publish it, and every app on the platform can call it directly. The logic is maintained in one copy, and every caller always gets a consistent result.

The Three Tabs

Collaboration Components has three tabs — “Snippet,” “Workflow,” and “Agent” — each with its own search, filter, and add.

Each tab has its own focus: Snippets target common business-logic units; the Workflow tab collects components consolidated from complete Workflow apps; the Agent tab collects the platform’s published Agents.

Snippet

What Is a Snippet

A Snippet is a self-contained unit that packages standardized, common business logic. Any processing logic reused across apps — generating copy in a unified format, standard data-cleaning rules, a fixed information-validation procedure — is a good candidate for a Snippet that all kinds of Workflows can call directly. The logic is maintained in one place, and every caller always gets a consistent result.

Creating and Editing

Basic steps to create a Snippet:

1. Go to “Collaboration Components” in the left menu and switch to the “Snippet” tab;
2. Click add, fill in the Snippet info as prompted, and finish creation;
3. Enter the editing interface to orchestrate the Snippet logic.

When orchestrating, note these characteristics:

• A Snippet’s editing interface is identical to a Workflow’s, with the same orchestration — nothing new to learn;
• Start and end nodes are optional in a Snippet — organize the internal logic as needed;
• Edits are saved automatically — no manual saving.

Publishing

A Snippet only takes effect externally after a manual publish:

1. Finish orchestration in the Snippet editing interface;
2. Run the publish action — only then can other Workflows call the Snippet;
3. An unpublished draft is visible and editable only to you, and cannot be called.

Tip: Drafts are never called by any app. In team collaboration, make sure a Snippet is published before telling other members to use it.

Permissions

Snippet permissions work the same as app permissions:

• Visible and usable only to you by default;
• Can be opened to selected team members — multi-select and select-all supported;
• The entry is “Permissions” in the Snippet’s more-actions menu;
• Permission settings and deletion are limited to Snippets you created yourself.

More Actions

Snippets support these more actions:

• Edit Info: Modify the Snippet’s name and other info;
• Permissions: Set the Snippet’s visible and usable scope;
• Export Snippet: Export the Snippet for migration or backup;
• Delete: Delete a Snippet no longer in use.

Calling a Snippet from a Workflow

Published Snippets can be called by other Workflows. When orchestrating a Workflow, pick the published Snippet you need through the canvas’s component entry to embed its processing into the current flow; the Snippet’s result can be referenced as a variable by downstream nodes. Callers do not need to care about the Snippet’s internals — just its inputs and outputs.

The Workflow Tab

A Workflow app can be published as a component for all apps on the platform to call. Steps:

1. Finish orchestration on the Workflow app’s “App Development” page and save the latest content;
2. Open the “Save” button’s drop-down and choose “Publish as Component”;
3. Configure the component info as prompted and confirm the publish;
4. After publishing, the Workflow syncs automatically to the “Collaboration Components → Workflow” tab and becomes a Workflow component.

When using it, note:

• Other apps add a “Workflow” node on the Workflow canvas and pick from the Workflow component list to call it; the called Workflow’s output is returned to the caller;
• “Publish as Component” is visible only for Workflow-type apps and is mutually exclusive with “Publish to App Square”; components published through this entry are not listed in the App Square;
• Ownership of a component published from a Workflow transfers together with the source Workflow’s ownership.

The Agent Tab

Published Agents sync automatically to the “Collaboration Components → Agent” tab — no extra action needed.

Other apps add an “Agent” node on the Workflow canvas and single-select one from the published-Agent list to attach and call, letting the Agent coordinate plugins, Workflows, Knowledge Bases, MCP Services, and more within the flow to complete the task. Unlike the “Workflow” node, which calls a fixed flow, the “Agent” node suits complex tasks that need model-autonomous decisions and flexible resource scheduling.

For creating and publishing Agents, see “Agent.”

Reuse Value and Governance Suggestions

The core value of Collaboration Components is converging duplicated construction scattered across apps into unified shared capabilities:

• One business standard: Each kind of business logic is maintained in one copy; every app calls the same component, so outputs stay consistent — no more divergent implementations;
• No repeated building: Once common capabilities are consolidated as components, new apps simply call them, significantly shortening the build cycle;
• Centralized maintenance: When business rules change, only the component itself needs updating — every caller picks up the latest capability, lowering maintenance cost across the platform.

We recommend the team plan component building and maintenance centrally:

1. Assign a clear owner to each kind of common capability to avoid duplicate components of the same kind;
2. Consolidate high-frequency business logic into Snippets first, forming the team’s shared capability library;
3. Use permission settings to control components’ visible scope, protecting the quality and stability of core components;
4. Before deleting a component, confirm its references so you do not break apps that are calling it.