Change requests are supposed to make managing change easier. But often, they show up as a vague Slack message, an incomplete ticket, or an email with no rollback plan. Reviewers then spend the start of the week tracking down missing details.
A well-designed Jira change request form solves this problem from the start. It asks the right questions for each change type, turns answers into Jira fields, and sends the request to the right owner and approver. This guide explains what to include, provides a ready-to-use template, and shows a Jira change request workflow you can adapt using Smart Forms for Jira and Jira Automation.
What should a Jira change request form capture?
The goal is simple: reviewers should be able to decide without needing follow-up questions. Only map answers your team will use to route, filter, or report on to Jira fields. Keep the rest as context in the form response.
Change title | Makes the request easy to find | Summary |
|---|
What type of change is this? | Decides the path: standard, normal or emergency | Work item type |
Business reason | Lets approvers judge value against risk | Description |
Affected system or service | Shows the impact, and drives routing | Component or Assets field |
Risk level and expected downtime | Triggers extra review and a maintenance window | Custom fields |
Requested date | Scheduling and change calendar | Due date |
Testing and rollback plan | Answers "what if it fails?" before approval | Description |
Change owner | Someone is accountable from day one | Assignee |
Teams to inform | Visibility without ownership | Labels or multi-select field |
Supporting files | Diagrams, test evidence and vendor documents stay on the ticket | Attachments |
Not sure if something should go in a Jira field or just in the form? Check out Designing Jira Intake Forms in 2026: When to Use a Field vs. a Form.
Change request form template: standard, normal and emergency changes
If you use one long form for every change, people will skip fields. Instead, ask for the change type first, then use conditional logic to show only the relevant questions. Smart Forms logic works with every element type and supports AND/OR conditions, so one form can handle all three paths.
Standard change (pre-approved, low risk) | None beyond the basics: title, service, date | Skips approval and goes straight to Scheduled |
|---|
Normal change | Testing plan, rollback plan, risk level, downtime | Risk review, then approval |
Emergency change | Related incident, emergency justification, rollback owner, approval contact | Notify the incident owner, then fast-track approval |
Add a few more rules and the form will adapt to the level of risk:
- Downtime expected or High risk → maintenance window, testing plan, communication plan
- Security impact → security reviewer and compliance notes
- External vendor involved → vendor contact and documentation upload
You can split long normal-change forms into steps using Page break, and place short fields side by side with Layout. This keeps the form easy to complete. For more examples, see Conditional Logic for More Efficient Jira Forms.
How to create a change request in Jira with Smart Forms
- Start by building the intake form. Add the questions from the template above. Use plain language. For example, asking "What should we do if this doesn't work?" gets better answers than "Describe contingency activities."
- Let the requester choose the change type, not the Jira setup. You can use a dropdown with your project's work item types, or keep a business-friendly question visible and use logic to set a hidden field with the matching type. Either way, Smart Forms creates the right work item type. For step-by-step instructions, see Create Jira Work Items from Forms with User-Selected Work Item Types.
- Create the work item and map the fields. In Settings, select Create a new work item, choose the project, and map each answer to its Jira field. You can now map affected services to Jira Assets objects: populate a choice element from the Assets field, then map it back. The change will be linked to the right service in your CMDB.
- Assign the owner. For internal forms, a user picker mapped to Assignee works well. For external forms, user pickers limit the form to verified Jira users, so instead ask "Which team should review this?" and let Jira Automation assign by team.
- Notify stakeholders by their role, not by name. Ask which teams should be informed (Security, IT Operations, Product owner), map the answer to Labels, and let Automation add watchers or send notifications.
- Collect evidence up front. Attachments are saved to the work item on submission, with validation for file type and size. See Collecting Attachments in Jira.
- Publish the form where requests begin. You can use a board sidebar shortcut, a JSM portal, a Confluence page, or an external link for vendors and partners. They do not need a Jira license. See Jira Issue Collector Alternative: External Issue Creation.
A Jira change request workflow with one form per stage
A common Jira change request workflow looks like this:
Submitted → Triage → Risk Review → Approval → Scheduled → Implementation → Validation → Done
Avoid putting every question into the intake form. Give each stage its own short form, attached to the same work item, so each person only fills in their part.
- Risk review (change manager) confirms impact, dependencies and whether approval is needed.
- Approval (approver) records the decision and any conditions.
- Implementation checklist (assignee) covers tests, logs and whether rollback was used.
- Post-change review covers outcome, incidents caused, and whether this should become a standard change.
Each form can update work item fields and change the status when submitted. For example, a completed approval moves the change from Approval to Scheduled automatically. See Update Jira Issue Status After Form Submission and Make Form Completion Part of the Jira Workflow.
Change approval in Jira with pre-filled forms
Approvers should not have to retype the change title and risk level from the ticket. Smart Forms now adds two actions to Jira Automation, so the approval form arrives at the right time with context already filled in:
- Attach Smart form with values adds the approval form when the work item moves to Approval and fills it with the mapped work item fields: title, risk level, affected service, and requested date.
- Send email includes the form link using the Smart Forms smart value. The approver opens it, chooses Approve, Reject, or Need info, and adds any conditions.
- Dynamic approvers let the form pick the approver from the answers, for example the security lead for security changes. See Dynamic Approvers: Let the Form Pick the Approver.
If you want to choose exactly which values go with the link, you can use URL parameters with Jira smart values. For example: &changeTitle={{issue.summary.urlEncode}}. Keep confidential data out of URLs, and remember that a form shared from a work item accepts only one response. For full setup, see NEW Jira Automation for Forms and How to Automatically Pre-Fill Jira Forms with Work Item Data.
Jira change management best practices
- Begin with one form and one workflow. Add stages, logic, and automation after you see which answers reviewers actually use.
- Ask in plain language. Requesters choose "What type of change?", and the form handles work item types, labels and assignees.
- Map only fields that drive action: change type, risk, service, date, owner, approval needed.
- Route emergencies differently. They need fewer questions, not none: incident, impact, rollback owner, approver.
- Keep user lists off external forms. Ask for a team or service, and assign internally.
- Never skip the post-change review. It's how normal changes become standard changes.
- Review responses every quarter. Look for fields that get skipped, requests that get misrouted, and approvals that stall. Export responses to Excel or Power BI, or, with Teamwork Graph connected, ask Rovo about past change responses from open forms (how it works).
FAQ
What should a Jira change request form include?
The change title, change type, business reason, affected service, risk level, downtime, requested date, testing and rollback plan, owner, teams to inform, and supporting files. Use conditional logic so standard changes stay short.
How do I create a change request in Jira without exposing Jira complexity?
Ask "What type of change are you requesting?" in plain language. Smart Forms turns the answer into the correct work item type, through a populated dropdown or a hidden field, and maps the rest of the answers to Jira fields.
How do I handle change approval in Jira?
Use a separate approval form. Attach it with Jira Automation when the work item reaches Approval, pre-fill it with the change details, and let its submission transition the work item to Scheduled.
Can people without Jira access submit change requests?
Yes. Share the form by link, on a website or on a Confluence page. Use team or service questions instead of user pickers so the form stays open to external requesters.
Final thought
Start with the questions your team always asks after a change is submitted, and build them into the form. Let requesters choose in plain language, map the answers that matter to Jira fields, send pre-filled forms to approvers, and let each submission move the work forward. That's a Jira change management process people actually follow.
Interested in trying this for your own change process? Start with Smart Forms for Jira, or share your workflow in the comments and we can help you set it up.
