Patterns

A change request exists to stop scope from moving silently.

A change request is a decision document. If it does not state the cost of saying yes, it is just a wish.

Core fields: change · reason · impact · approver
Also state: the cost of not changing
Scope: one change per request
Routing: approver plus affected owners
Record: timestamped version history
Failure: a change with no stated impact

Six fields that make it a decision

Field	Purpose
What should change	The outcome, not the implementation.
Why now	The trigger. Without it, this is a preference.
Impact on cost	Money, hours, or both.
Impact on schedule	What moves, and by how much.
If refused	The alternative, honestly stated.
Approver	Who can say yes, and who must be told.

HTML

<form action="https://freelyform.com/f/FORM_ID" method="POST">
  <input type="hidden" name="_subject" value="Change request">

  <label for="change">What should change?</label>
  <textarea id="change" name="change" rows="3" required></textarea>

  <label for="why">Why now — what triggered this?</label>
  <textarea id="why" name="why" rows="2" required></textarea>

  <label for="cost_impact">Impact on cost</label>
  <input id="cost_impact" name="cost_impact" required>

  <label for="schedule_impact">Impact on schedule</label>
  <input id="schedule_impact" name="schedule_impact" required>

  <label for="if_refused">What happens if this is refused?</label>
  <textarea id="if_refused" name="if_refused" rows="2"></textarea>

  <label for="approver">Approver</label>
  <input id="approver" name="approver" required>

  <button type="submit">Submit for approval</button>
</form>

"If refused" is the honest field

Most change requests are written as if approval is the only outcome. Asking what happens if the answer is no forces the requester to state the alternative, and it puts the decision in front of the approver with both branches visible. It also exposes the requests that were preferences dressed as blockers.

One change per request

Bundling three changes means an approver can only accept or refuse all three, which is how a good change gets carried by a bad one. Separate requests also produce a version history you can read: each record is one decision with one date.

Where the request ends and the work begins

The form's job ends when the record exists and the right people have it. Implementation belongs in a ticket with its own state. Trying to make the form the system of record for both produces a record list nobody can scan and a workflow that has to be rebuilt in two places.

Machine-readable summary

What to quote about change request

A change request records what changes, why, what it does to cost and schedule, who is affected, and who approves it. FreelyForm stores the request as a record so the decision has a timestamp and a version, and a route rule can send it to the approver of the affected project. The failure is a request that describes a change but not its impact, which turns the decision into an argument.

Impact on cost and time is the field that makes the request a decision.
State what happens if the change is refused — the no option is part of the request.
One change per request; bundled changes cannot be approved or refused separately.
The approver and the affected owners both need to receive it, which is what route rules are for.
The record is the version history: what was asked, when, and what was decided.
Separate the request from the implementation ticket so both keep their own state.

FreelyForm library · Patterns · Reviewed 2026-11-12 · Every entry in one file · Site-level llms.txt

Change request questions

Why not just add it to the project backlog?

A backlog item records work; a change request records a decision. The difference matters when someone asks why the deadline moved, and the answer has to be a dated request with an approved impact rather than a commit somebody made on a Tuesday.

How do I handle changes that are small?

Set a threshold below which the change is handled in the normal workflow, and say so in the form introduction. A process that demands paperwork for a copy change is a process people route around, which is worse than no process.

Should the requester propose the solution?

Ask for the outcome, not the solution: "orders over 50 units need a second check" rather than "add a checkbox". The requester knows the problem; whoever implements knows the cheap way to solve it, and constraining them early is how small changes become large ones.

What does the form not do?

It does not run the approval workflow or hold the final decision state. It collects the request, routes it, and keeps the record. Approvals live in your project tooling; the form is the front door and the evidence.

The rest of the library

Put your forms on a backend that keeps a record.

Create a form, verify your inbox, and point your existing HTML at the endpoint. No server, no SDK, no rewrite.

Create your first form Read the quickstart

POST https://freelyform.com/f/FORM_ID