Change templates

Change templates

A change template is a saved skeleton for a change request. Pick a template when you raise a new change and the type, risk, impact, plan, and rollback are pre-populated. Useful for changes you make often — “Apply security patches to the file server”, “Roll back Windows printers update”.

What’s on a template

• Name + description — what kind of change this is.
• Change type — standard (pre-approved, low risk, repeatable), normal (requires approval), or emergency (out-of-cycle, post-hoc review).
• Risk — low / medium / high.
• Impact — none, minor, or outage.
• Implementation plan — the steps you’d write in the change body. Plain HTML, sanitised.
• Rollback plan — what you’d do if the change goes wrong.
• Affected services — comma-separated list, surfaces in the change calendar.
• Downtime required — flag.
• Pre-approved — flag. Standard changes are usually pre-approved; ticking this skips the approval workflow when the template is used.

When to write a template

You’re tempted to create one when:

• You’ve raised the same change three times in a year.
• A specific change type has compliance requirements (e.g. WSUS patch cycles) and you want to enforce the rollback plan is always written.
• Risk/impact for a class of changes is uncontroversial — capture it once.

When not to write a template

If the change is genuinely one-off, raise it from a blank change form. Don’t write a template that only ever fires once.

Gotchas

• Marking a template pre-approved means changes raised from it skip the approval matrix entirely. Use this only for low-risk, well-documented standard changes.
• Toggling is_active false hides the template from the picker but doesn’t affect changes already raised from it.
• Implementation and rollback HTML is sanitised on save. Inline scripts and event handlers are stripped silently — paste plain text or simple formatting.

Related

• Change requests
• Change freezes
• Approval chains