Change Requests

Open the pageCopy Anchor Link

Baselines in the project's sidebar, then the Change Requests tab. The badge on the sidebar entry counts the requests still open: everything but the rejected, verified and closed ones. The list shows each request's reference, its title with the baseline it is raised against and the stakeholder who asked, its reason, its priority, its impact level (or Not yet), its status and when it last changed. Sort by number, title, reason, priority, impact, status or the last change; filter by reason or status, or search by reference or title; Clear Filters drops every filter.

Raise a requestCopy Anchor Link

Press New Change Request. The editor is in three parts:

• The Change: a Title, the Reason it is raised for, its Priority, the Baseline it is raised against (the frozen baselines of the project; leave it empty when none applies), the stakeholder who asked under Asked by (the client's people from stakeholders; that seat co-signs the impact once an account is linked to it), and a Description of what is asked for and why, in the words of the person who asked.
• Records Touched: the epics, stories, requirements, rules and use cases the change reaches. With a baseline named, its records are offered; without one, every approved record of the project is. Each pick becomes a link from the request; an approved request unlocks the ones its baseline holds.
• Impact: the Impact level, the Schedule impact in days, the Effort in hours, the Cost, and the prose on Impact on scope and Impact on risk. Leave what you do not know; the analyst fills it later, or Heimdall does.

Raise Change Request writes it as Submitted, numbered from the project's change requests sequence, with you as the person who raised it, and the people watching the project hear change_request.created.

A title and a reason are enough. The impact can wait for the analyst; the records can be named later, as long as they are named before the approvers decide, since the approval unlocks what is named at that moment.

Analyse the impactCopy Anchor Link

Open the request's flyout. Move to → Under analysis says the analyst has it. Then either write the impact in the editor (Edit), or press Analyse with Heimdall: Heimdall reads the request, the impact you already wrote, the baseline and every record it names with what links to each, and answers with a summary, the scope and the risk as prose, a schedule in days, an effort in hours, a level, the records it believes the request forgot and the questions to put to the client before deciding. The draft lands under Heimdall's reading in the flyout; the numbers and the prose fill only the fields you left empty, and never replace a number you wrote. Ask again after you edit and Heimdall weighs what you wrote against its own reading. A request still only Submitted moves to Under analysis when Heimdall reads it, because it has now been analysed. How the reading is made, what it costs and where it stops is on impact analysis.

For a change that deserves more than one lens, press Convene the Council: the council sits on its Change impact moment with Odin, Loki, Týr and Frigg by default, each reading the same brief through their own lens, and Heimdall's verdict ranks what they found. The sitting appears under The Council in the flyout as the voices speak; the button returns when the sitting is done.

Submit it to the approversCopy Anchor Link

With the impact written, the Approval bar offers Submit for review to anyone with change-request:approve. The request moves to Awaiting approval; the approvers are the people the project's Change request policy names (the project manager role by default, under the Every approver rule) and, when a stakeholder asked for the change, that stakeholder through the guest account linked to their seat. Each is told, each decides once, and the request waits.

What the approval does when it carries:

• The request becomes Approved at version 1, stamped with the time.
• Every baseline item the request names is unlocked, with the request recorded as the reason; the rest of the baseline stays frozen.
• A requirement or a rule among them that no other frozen baseline holds moves from Baselined back to Approved, so its editor opens again; the next edit marks it changed since its approval and the approval bar asks for a new submission. An epic, a story or a use case is simply free.
• change_request.status_changed goes out beside the approval's events.

A rejection settles the request as Rejected with the approver's words under Why it was refused; the baseline stands as it was. A rejected request goes back Under analysis by hand when the team wants another round, and is submitted again as a new request. A request for changes holds it until it is edited and resubmitted.

See the change throughCopy Anchor Link

An approved request moves by hand along the rest of its lifecycle from the row menu or the flyout: Implementing while the team makes the change, Implemented when it is made, Verified when someone with change-request:verify confirms it landed as asked (the flyout names who and when), and Closed at the end. A request can also be closed from Submitted or Under analysis when it is withdrawn before anyone decides it. The moves into and out of the gate (Awaiting approval, Approved, Rejected) are the approval engine's and the menu does not offer them; while a request is under review, the menu is closed until it is withdrawn.

Edit and deleteCopy Anchor Link

A request is edited until the approvers decide it: Edit reopens the editor for the words, the records touched and the impact while it is submitted, under analysis or awaiting approval; every save is a version. An approved or rejected request no longer changes.

Delete Change Request removes a request that was never agreed, with its links and its versions; its number is never handed out again. A request past its gate is closed rather than deleted.