Ready-Made Solution Versions

Ready-made solution versions

A version defines which resources and setup steps a user receives when installing a ready-made solution. The author explicitly selects agents, segments, landings, and triggers, while the cabinet adds their required MCP servers, knowledge base content, custom metrics, and variables as dependencies. New installations and upgrades use the highest-numbered published version.

The versions page shows every release and its state. Select the required version to open its contents and available actions.

Source project

The source project is the author's working project from which the ready-made solution takes its resources. If it does not exist yet, click Create Source Project. After creation, open it through the project name at the top of the page.

Configure the required resources in the source project first. If an agent or landing has changed, publish its working version before publishing the solution version: the ready-made solution receives published state, not unfinished edits. Before release, test agent instructions, segment, landing, and trigger relationships, MCP, knowledge base content, metrics, variables, and solution permissions in a real scenario.

Creating a version

1. Click Create Version.
2. Review the explanation in the draft creation dialog.
3. Click Create.

A ready-made solution can have only one draft. If a draft already exists, the create action opens it. Otherwise, the cabinet assigns the next number and copies the resources and steps of the latest published version into the new draft. Release notes stay empty, and the default update mode is After Confirmation.

Configuring the draft

On the version page, choose how the update is applied. After Confirmation leaves the update start to the user. Automatically updates an installation without confirmation only when every version between the installed and new versions is automatic. An automatic version cannot add, change, reorder, or remove setup steps: the complete set must match the previous published version. It also cannot remove installed resources or require the user to reconnect MCP access or reconfigure a landing button subscription. Use After Confirmation for such changes.

Enter release notes and click Save. Describe what changes for the user: new capabilities, changed settings, important limitations, and actions required after upgrading.

In the resources section, choose a primary resource type, open the resource selector, use search when needed, choose the required resource, and click Add Resource. Agents, segments, landings, and triggers can be selected explicitly.

The cabinet adds dependencies automatically and shows which resource or setup step requires each one. Dependencies can include segments used by a landing button or trigger, an agent's MCP servers and knowledge sources, custom metrics, knowledge folders, and project or lead variables. An automatic dependency cannot be removed separately; change or remove the primary resource or step that requires it. An inactive source shows a warning, while a deleted or unavailable source must be fixed before publication.

Do not change the name, type, or constraints of a released variable while keeping it as the same resource: an installed solution may already store a value in the old format. For an incompatible change, create a new variable in the source project and move solution resources and steps to it.

Replacing resources

Replacement is used when a new resource must take the previous resource's place while preserving its link to installed copies. Select a new source of the same type in the replacement selector. You can prepare several replacements at once, including a resource from the previous version that is no longer in the current composition.

Click Check Final Composition. The cabinet recalculates the complete resource set with automatic dependencies. Review the primary resources and dependencies that remain, then click Apply All Replacements. All selected replacements are applied together; if the composition changed after preview, run the preview again.

Removing a primary resource excludes it and any dependencies no longer needed. If an agent is referenced by a setup step, change or delete that step first.

For actions users must complete after installation, click Add Step. Open an existing step to edit it, or use remove step directly in the list. Setup step types and fields are described in Ready-Made Solution Setup Steps.

The update mode, release notes, resources, and steps can be changed only in a draft. A published version is read-only; create a new draft for the next release.

Deleting a draft

Delete Draft removes only that draft's resources, release notes, and steps. Published versions and existing installations are unchanged. The action requires confirmation; after deletion, a new draft can be created from the latest published version.

Publishing

Before publishing, keep at least one primary resource in the version, review the final composition, unavailable dependencies, and setup steps, and publish working versions of changed agents and landings. Then click Publish. In addition to version-management permission, this action requires permission to publish app versions.

After publishing, the highest-numbered version becomes available for new installations and upgrades. Installations using After Confirmation wait for user action. An automatic update runs only across an uninterrupted chain of automatic versions.

Catalog publication

Publishing a version and publishing the ready-made solution itself in the catalog are separate stages. When the app card and at least one version are ready, use the submit for moderation button. While the request is being reviewed, the cabinet shows the pending status.

If moderation rejects the request, the cabinet shows the moderator's comment. If no comment was provided, the card says so instead of inventing a reason. Address the feedback and use the same button to submit the solution again.

A member without publication permission can view the moderation state but cannot submit a request or change solution visibility. Ask the app owner or a member with publication permission to perform these actions.

After approval, you can hide the solution from the catalog and show it again without another moderation review. This controls the app card's visibility but does not remove existing installations.

Version statuses

• Draft. The version can be configured and edited, but cannot be installed in another project.
• Published. The version participates in selecting the current release for installation and upgrade.

Installed solutions

An installation can upgrade only to the newest published version. During upgrade, the cabinet synchronizes resources with the new version and applies its setup steps; a manual transition may require user action for required steps from skipped versions. Selecting an arbitrary older version and rolling back to a previous version are not supported.

Before a manual upgrade, the user sees release notes and impacts that require attention: resource removal, reconnecting MCP access, or reconfiguring a landing button subscription. Automatic versions are applied in the background only across an uninterrupted automatic chain with no manual boundary.

Developer dialog access

The owner of the installing project separately decides whether to grant the developer access to ready-made solution dialogs. Access is enabled by default during installation, but the user can turn it off before installation or later on the installed app page. The solution author does not control this choice for another project. This is not full project access: the developer sees only dialogs in which solution agents participated.

The author can also hide installed agent settings. In that case, the project user sees Settings Hidden and can test the agent, but cannot change its configuration.

If an action is unavailable

• if the versions page is missing, verify that the app was created as a Ready-Made Solution;
• if the cabinet requests a source project, create it before the first draft;
• if a draft cannot be created or saved, check permission to manage versions;
• if publishing fails, keep at least one primary resource, fix unavailable dependencies, publish agent and landing changes, and check permission to publish versions;
• if a resource is already included, choose a different source or prepare a replacement of the same type;
• if the replacement preview is stale, click Check Final Composition again before applying replacements;
• if an agent cannot be removed from resources, first change or delete the steps that use that agent;
• if an automatic version cannot be published, restore setup steps to the previous published version's composition and check whether the release removes resources or requires MCP or landing button reconfiguration; otherwise choose After Confirmation;
• if the cabinet reports that a released variable changed, create a new variable and replace references to it in resources and steps;
• if fields are read-only, the version is no longer a draft;
• if create opens an existing version, the app already has a draft.