Change request form
A change request form is a gate, not a gate operator — it records the what, the why and the risk before anything ships, so if something breaks there is a record of what was supposed to happen and what went wrong. The approvals still happen in your tickets system; this form is the intake that populates it.
The form beside this text is live. Fill it in and submit it — it validates exactly as it would for a real respondent, and saves nothing.
Change type field automates routing
A dropdown of standard/normal/emergency means the form can route to the right approval queue without triage. Emergency changes route fast; standard changes follow process without every approval person reading each request.
Rollback plan recorded from the start
Asking for it on the form, not after approval, is what catches incomplete plans before they cost you. A required text field forces the requester to think about what breaks and how to undo it.
No card required.
Change Request Form
Live previewHow to build this form
6 steps in the editor. Nothing here needs a paid plan.
- Add short text fields for requester name and team.
- Add a text field for the title or summary of the change.
- Add a select field for change type (standard, normal, emergency) — it stays countable and ties to your approval workflow.
- Add a long text field for reason or business case, and another for the rollback plan.
- Add a select field for impact or risk (low, medium, high).
- Add a date field for proposed implementation date and a text field for approver name, then export to CSV when approvals come back.
Fields in this form
9 fields, using 4 of the 19 field types available.
| Question | Field type | Required |
|---|---|---|
| Requester name | Short text | Yes |
| Team | Short text | Yes |
| Change title | Short text | Yes |
| Change type | Select | Yes |
| Reason or business case | Long text | Yes |
| Impact or risk level | Select | Yes |
| Rollback plan | Long text | Yes |
| Proposed implementation date | Date | Yes |
| Approver name | Short text | Optional |
What goes wrong with this form
Specific to a change request form, not general advice about forms.
Change type as free text
A dropdown of your change types (standard, normal, emergency) lets you filter and sort requests by type in the CSV. Free text means triage work every time someone misspells it, and no routing at all until someone reads it.
No rollback plan field
This is the field that prevents panic. Asking for it on the form forces the requester to think through the undo before they are in an incident, and recording it means the on-call person has it during the outage instead of writing it under time pressure.
No impact or risk assessment
A select field (low/medium/high) stays countable and informs urgency. Free text about risk produces vague language that does not route or prioritize — a structured field is what lets you sort by actual impact.
Questions about this form
What should a change request form ask for?
Requester and team, change title, change type, reason, impact assessment, rollback plan, proposed date and approver name. That is nine fields and it is comprehensive — anything else belongs in the conversation after approval, not the intake form.
Does this form approve the change?
No. This form records the request. Approvals still happen in your ticketing system or change advisory board, and what this form does is populate your audit trail. The form is the intake; approval is a separate step.
Why do I need to state the rollback plan if the change works?
Because when a change does not work, you will not have time to figure out how to undo it — you will need the plan you wrote beforehand. Writing it up front is how you think through the risk before you are in an outage. It is the difference between "we tested this" and "we tested this and we know how to undo it".