Deliverables, milestones and formal reviews¶

A deliverable records an output the project promises to provide. A milestone gate checks whether selected work and outputs have met a checkpoint's requirements. A formal review routes a decision through an established workflow and keeps the result associated with the project or selected record.

Availability: This guide describes the intended journey in the inspected Final Screens. The frontend remains a preview using sample records and local action dialogs that do not save your changes. Connected saving, review launch, permissions, recovery and deployment have not been verified. The behaviour described below comes from the inspected implementation; where the design promises more, the limitation is explained beside the relevant task.

Use project setup and lifecycle to establish the project and execution to organise and complete its work. Reviewers carry out their assigned approval work through the workflow journey.

What these records tell you¶

For managers, these records separate work performed from outputs accepted and decisions made. Executives should examine the chosen criteria and relevant decision history before treating an approved checkpoint as evidence of readiness. A gate may deliberately require only some selected items. No financial return, contractual certification or guaranteed delivery date follows from a status badge.

Before you begin¶

Confirm the workspace and selected project. Viewing these records requires project-viewing permission. Adding deliverables and creating, editing or evaluating gates requires project-management permission. Requesting a formal review requires project-governance permission. Being listed as an owner, requester or project participant does not grant those permissions automatically.

Agree what output or decision is needed, and use saved records from the same project. A formal review also needs an appropriate published review flow. Ask the process owner to confirm its purpose and approval route. A suggested flow is not proof that it is suitable: the current suggestions are inferred from the flow's name and description, and work-item completion flows are not represented correctly in that suggestion list.

The inspected request does not select an individual approver or set a review deadline. Those decisions belong to the chosen workflow and its configuration.

Add a promised output¶

1. Open the project and choose Deliverables, then Add deliverable.
2. Enter a recognisable Deliverable name, such as “Branch opening checklist.” Names are required and can contain up to 256 characters.
3. In What will be delivered, explain the output and how the team will recognise it. Keep the description within the stored limit of 2,000 characters.
4. If formal acceptance is required, select the intended Acceptance purpose. For acceptance of this deliverable, use Deliverable acceptance. Leaving the purpose empty does not prevent a later separate review request.
5. Enter a Due date if the team has committed one. No date means none has been recorded; it is not an assurance that delivery is on time.
6. Choose Add deliverable. Once the connected action is available, refresh the deliverable list and confirm the saved record before starting a review.

Adding a deliverable creates a planned output record. Selecting an acceptance purpose does not launch a review or approve the output. This action does not upload a document, assign a deliverable owner, attach the output to a phase, or save a separate acceptance checklist. No ordinary edit or delete action is provided by this inspected deliverable surface. Check the details before submitting and ask support about correction of an incorrectly saved record rather than assuming an edit control exists.

Read the deliverable board¶

The intended board groups work into Needs request, In review and Accepted, with search, state filtering, due-date ordering and Refresh list. These are useful presentation choices, but their connection to saved records remains unfinished. Clear filters and refresh before concluding that an output is missing. A load failure or denied access must not appear as an empty list.

Read acceptance and review progress separately. A new deliverable remains planned when a review is requested; the current implementation does not set a separate in-review state at that point. The associated workflow can nevertheless be requested or in progress. A rejected review records the deliverable as rejected, clears its acceptance time, and may appear in the design's review column as returned work. An approved acceptance review records acceptance and its time.

Milestones shown beside a deliverable are checkpoints that depend on that output. Their presence does not mean those milestones block acceptance of the deliverable. The current list includes all referencing gates, including approved ones; it is not a count of unresolved blockers. If a screen says “Blocked by” a checkpoint, verify the actual relationship with the project owner.

Requester information is also limited. Where a workflow requester is unavailable, the read model can fall back to the project owner. Do not treat that displayed name as proof of who created or submitted the deliverable. Use the actual review record when attribution matters.

Request a formal review¶

1. From the relevant deliverable's actions, choose Request review. The request companion is also intended for milestone and work-item decisions; keep it attached to the correct selected record.
2. Choose Review purpose, then a suitable Review flow. Confirm the flow with the process owner if its name or suggested purpose is ambiguous.
3. Choose Record type and select the saved record. Recheck its name and project. Changing the purpose may require a different record type and flow.
4. Enter a clear Review title and explain the decision in What should reviewers confirm. The design asks for a title; the service can fall back to the project title when none is supplied. Providing a specific title makes the review easier to recognise.
5. Add a Reference if useful. Keep the title within 256 characters, the description within 2,000 and the reference within 64. References are normalised to uppercase.
6. Check the selected record and purpose, then choose Send request once the connected action is available.
7. Refresh the associated review information. Submission first saves a request; the workflow starts through background processing. Wait for its workflow identity and progress before treating it as opened. The design's promise of immediately opening the workflow and returning updated record details is ahead of the implemented response.

The request companion inspected here primarily shows deliverables, milestones and work items. Project-level decisions are intended to appear in the project overview, but their complete connected request journey still needs verification. Do not substitute a milestone for a project-level decision or assume approval automatically performs the approved business change.

Avoid sending repeated requests to make a delayed workflow appear. The implementation permits multiple review records for the same subject; it does not enforce one active review. If the result is uncertain, refresh and ask support to identify the original request before resubmitting. Approval, rejection and subsequent review attempts can change the recorded outcome; acceptance is not permanently locked by the first approval.

Create a checkpoint¶

1. Open Milestones and choose Create gate.
2. Enter a Gate title and a description of the checkpoint. Titles are required, up to 256 characters; descriptions have a stored limit of 2,000 characters. Add a Target date if agreed.
3. Select saved Execution items, Execution groups and Deliverables that the checkpoint depends on. Select each record once, and keep all criteria within this project.
4. If only a subset of the explicitly selected items must finish, set Required completed items. Otherwise leave it blank to require every selected item. A supplied number must be at least one and cannot exceed the number of explicitly selected items.
5. Turn on Require workflow approval before sign-off when this checkpoint needs formal approval in addition to its work criteria.
6. Review Selected criteria, then choose Create gate. Refresh the milestone board after a confirmed save to inspect the evaluated result.

A gate must have at least one selected item, group or deliverable, or require workflow approval. It can be a purely formal approval checkpoint. Selecting no criteria and requiring no approval is not a valid ordinary creation request.

The service evaluates these requirements as follows:

The explicit-item threshold does not relax the group or deliverable requirements. For example, a gate can require two of three individually selected items, all work in a selected phase, and both selected deliverables. All three conditions must pass. Selecting both a group and an item from that group does not exempt the group's remaining items.

Group membership is live. Adding or moving unfinished work into a selected group can make its criterion fail on reevaluation; moving it out can change the result. Agree the intended scope before interpreting a checkpoint's status.

Evaluate or change a gate¶

On Milestones, review the gate's criteria and workflow status. Open its Evaluate gate companion, check the current summary, and choose Run check. This action recalculates the result from saved work and decisions. It does not collect an evaluation note, override a failure, fetch fresh repository evidence or request approval. A read-only refresh and a gate evaluation are different actions.

The current evaluate design shows item and deliverable counts and workflow approval. Gates may also require entire sprints or phases. Inspect those group criteria as well; the companion needs to expose them clearly. “Ready” in a count must not be mistaken for the completed state required by the service.

To change a checkpoint, open Manage gate, check its identity, and revise the title, description, date and selected criteria. Confirm the completion threshold and workflow requirement before Save gate. The backend accepts replacement values for both, while the inspected manage companion currently shows them as descriptive text; connected editing or faithful preservation of those values remains unfinished.

Saving a change resets the gate's evaluation and evaluates it again. It is not a cosmetic edit that leaves the old decision untouched. The achieved time can change, and a gate can cease to pass when requirements are no longer satisfied.

Approval-history limitation: The evaluator accepts any recorded approved milestone sign-off for the gate. The displayed review summary instead selects the most recently requested review. An older approval can therefore make the gate pass even while a newer review is pending or rejected. Editing the criteria does not require a new approval tied to that revision. If the gate status and current review disagree, ask the process owner and support to reconcile them before making a release or closeout decision; repeatedly running the check does not resolve that policy gap.

Recovery and responsibility¶

Project owners keep criteria and promised outputs meaningful. Process owners maintain review flows and resolve conflicting decisions. Administrators manage access. Support investigates delayed processing and uncertain results using authorised internal evidence; it should not erase review history or fabricate approval to make the board look complete.

For imported technical proof, continue with repositories and engineering evidence. Attributing or accepting repository evidence is separate from accepting a deliverable or passing a gate.

Completing a gate does not close the project. Project closure remains the separate lifecycle decision. No additional per-review price or quota is established by this inspected path; wider licensing and environment availability need their own evidence.