Publish and activate fixed app releases
Freeze an app's execution content, deploy a saved release, and roll back safely.
A shared release is an immutable snapshot of an app's definition, parameters, model policy, connector configuration, and provisioned workflow recipes, paired with a compatible renderer. Use it when users should run a fixed experience while you continue editing the draft.
Publishing and activating are separate actions. Publish release captures a release. Activate release selects which saved release serves the shared deployment. Publishing alone does not change the active deployment.
Publish
- Save and verify the intended app definition.
- Review Parameters, model choice, connector selections, and workflows.
- Open Versions → Shared releases.
- Review the displayed definition and parameter revisions.
- If offered more than one, choose the Renderer version.
- Choose Publish release and wait for confirmation.
A compatible admitted renderer is required. If none is available, ask the platform administrator to provide one. If the app changes during capture, Strive refuses to publish the stale selection; refresh state and review the source again.
Activate or roll back
Choose Activate release on the desired history entry. The active entry is marked Active. Use Open active release to inspect the selected experience.
To roll back, activate an earlier saved release. This changes subsequent admissions to that release's configuration. A run that already selected a release retains its original pinned recipe, parameters, model policy, and configuration. Editing the draft, activating another release, or deactivating does not rewrite an admitted run.
Deactivate and recover
Choose Deactivate to stop the shared release deployment from accepting new release-backed work. History remains available for later activation. Deactivation is not a history deletion or a rollback of finished output.
If the app or deployment changed, Refresh state and review your selection again. If a response could not be confirmed, Retry same request repeats the original operation rather than creating a second publication. Do not change the selection and then treat it as the same uncertain request.
Current ownership, access, lifecycle, and artifact availability remain checked even for an immutable release. A release does not freeze permissions or make a trashed app usable. Earlier releases without captured workflow content cannot substitute current draft recipes for workflow-backed execution.