Overview and manage import of objects and map their metadata to match platform configuration. Imported objects should be handled as objects that are ready for release and should not be able to be modified by platform users.
Validate objects matching recipes from a product perspective rather than a publication perspective.
Validate that objects matched by recipes meet required metadata and approval criteria before release to prevent accidental exposure.
Track release states (scheduled, in progress, released) with a complete audit trail of who initiated, what was included, and where it was delivered.
Provide safe rollback of released units and controlled re-release when updates or corrections are needed, maintaining traceability.
Schedule releases and automate delivery workflows, reducing manual effort and ensuring consistent timing across channels and markets.
Choose from approved objects and mark them for release, ensuring only vetted content structures move to distribution.
This feature packages the externally visible contract updates and closes the implementation with documentation and verification steps. It solves the integration and maintainability side of the refinement by ensuring the OpenAPI surface, BI event catalog, superseded spec references, context budgets, and full test runs all reflect the new version/language-scoped release behavior. The work regenerates the API contract, updates contract tests, documents the mandatory event context fields, and records the relationship back to the earlier release-manager specification so future readers understand which behavior is now authoritative. It then validates file-size budgets, keeps oversized fixture payloads out of inline tests, and runs the full build, test, and dev-environment release integration checks including quickstart flows. The main acceptance signal is that the refined behavior is not only implemented in code but also exported, documented, and proven through automated and external integration runs. This is also where residual drift is caught: if API shapes, event payloads, or test assets do not match the new release identity and routing model, this feature must fail before the change is considered complete.
This feature establishes the version- and language-aware release domain so the rest of the refinement can work on a correct foundation. It solves the core modeling problem from the spec by making language and recipe version first-class release attributes, separating historical classification from unique record identity, and updating service contracts so release, review, listing, locking, and rollback can all operate on the refined scope. The implementation updates the release models, repository contracts, and service interfaces, then threads the new parameters through existing call sites until the solution builds cleanly again. It adds the fan-out result model, expands release and decision records, changes the in-progress lock identity to include language but exclude version, implements repository filtering and canonical language handling, and performs the initial compile/test stabilization across API, Azure services, orchestration, and tests. A key constraint here is that the lock slot must serialize by (workspace, recipe, target, language) regardless of version, while history queries must still support optional language and version filters without treating the tuple as a unique ID. The work also has explicit context-budget constraints on ReleaseRecord.cs and ReleaseService.Create.cs, so the model/factory reshaping and plumbing must preserve behavior while reducing or controlling file growth.
This feature delivers the concurrency and automation rules that follow from the refined scope: releases serialize per recipe/target/language slot, while scheduled and automatic releases honor explicit language selection. It solves two operational problems at once: preventing overlapping work on the same live language slot regardless of version, and ensuring non-manual release paths use the same language-aware behavior as manual release. The technical approach extends the fan-out release path into locking behavior and then routes scheduled and change-triggered executions through that same shared machinery. Tests and implementation cover same-slot contention across versions, different-language parallelism, finally-block lock release, schedule binding language persistence and validation, audit coverage, orchestration expansion by configured languages, stale or missing language handling, and no-release decisions when automation has no valid language scope to act on. The main constraints are that version must not participate in the active lock identity, blocked languages should return language-specific outcomes without stopping sibling languages, and automation owns its language selection through binding criteria rather than global release configuration. Acceptance is shown by concurrent multi-language scenarios, correct per-language proceed/block results, and scheduled or event-driven runs that release only configured languages while recording explicit decisions for empty or stale selections.
This feature delivers the new release-history and rollback behavior where users select a concrete historical release record and restore it, even across versions, within the same recipe/target/language slot. It solves the earlier rollback identity problem by making record ID the rollback-selection key, exposing cross-version history and current-live lookup, and enforcing rollback concurrency on the same language-scoped slot used for release. The implementation updates service behavior, repository-backed queries, API routing, and response contracts so history can be listed across versions or constrained by route version, current-live can be resolved server-side per slot, and rollback can be invoked from a workspace-level route using the target release record ID. Tests cover cross-version history semantics, case-insensitive language filters, successful-only latest lookup, rollback record linkage fields, slot-derived validation, lock conflicts, rejected non-completed targets, and the removal of the old hierarchy-scoped rollback surface. Key constraints are that rollback must validate workspace scope and completed-successful target state, derive the slot from the selected record rather than caller-provided version context, and allow redeploy of the current live release if requested. Acceptance is visible when a user can release multiple versions for one language, discover the desired historical record through cross-version history, restore it via the workspace-level rollback route, and observe unaffected history for other languages.
This feature delivers the main user-facing refinement that review and manual release operate on one selected recipe version and one or more selected languages, producing one independent release record per language. It solves the previous recipe-level ambiguity by ensuring readiness, validation, snapshots, release execution, API contracts, and emitted records all align to the exact version-language scope chosen by the user. The implementation spans request/response DTOs, endpoints, review and release services, snapshot collection, event emission, and end-to-end tests. Review gains required language input, selected-language validation against the resolved subversion, per-language readiness reporting, and language-sensitive gating; release uses a shared fan-out pipeline that validates the scope once, loops per language, creates per-language records and decision records, narrows outputs to the selected language, returns a multi-outcome response, and stamps audit/BI events with mandatory language and recipe version context. Important acceptance signals are that unselected languages must not influence review or release outcomes, unavailable languages must fail the request before records or locks are created for manual release, and each selected language must remain independently processed so a blocked or failed language does not abort siblings. Production force behavior, copied force-release reason, version-scoped routing, and one-event-per-language semantics are also central edge conditions covered by this feature.
Implements configuration storage, criteria, change event handling, object matching, debounce, feature flag control, decision recording, and associated endpoints/tests for US3 and change-triggered auto-releases.
Implements the release review workflow, manual release creation, concurrency management, immutable snapshot capturing, force-release governance, and related endpoints/tests supporting US1 and US2.
Provides schedule management, bindings between schedules and recipes with version scope, runner orchestration, evaluation, and associated endpoints/tests for US4.
Enables querying of release and decision records with filters, detailed views, rollback functionality for reverting releases, and related endpoints/tests for US5 and US6.
Related requirement tasks from other projects
Description Please list them (HTML, HTML5, zip, archive, Help files)? Platform Status: PPT Status: MVP: Yes Must Have: Priority 1 (A)
View in Azure DevOps →Description Platform Status: PPT Status: MVP: Yes Must Have: Priority 1 (A) Use Case Does your system deliver to Salesforce knowledge or have a supported connector? Notes Merged with 3.36 - print and digital.
View in Azure DevOps →