CRM Change Request and Release Template
Three documents and three sheets that check every proposed field change against your live reports and automations, not against memory.
Free download · No account needed
Change management vendors and generic templates all ship the same field: Impact Assessment, a textarea asking what might break. Corrigan Fleet Services, a 90-person fleet operator running Salesforce, filled that box in from memory for a year. Every change request arrived as a Slack message and got actioned the same day. A retroactive count of that year found 34 requests nobody had logged anywhere, 12 of which deleted, retyped, or repurposed a field already in production use.
This pack runs the check instead of asking for one. Every request to delete, retype, or repurpose a field lands in the Change Request Queue first. Then it gets tested against the current report and automation inventory before anyone approves it, the same inventory a field dictionary and a stale-field audit already build. Run against Corrigan's 12 historical field-change requests, checking 18 reports and 26 automations found 4 with a live dependent the requester never named, a third of the population. The other 8 cleared and shipped the same day as Standard changes.
One of the four flagged cases had already shipped before the check existed: a field called Renewal Risk Score, deleted as believed unused after 90 days. It fed a weekly dashboard as a column and a filter, and a flow that alerted customer success above a risk threshold. Both went silent for 12 days before anyone traced the blank dashboard back to the deletion. Salesforce keeps a deleted custom field recoverable for only 15 days (Cloud Answers, "Salesforce Data Recovery Without a Backup"), and that window had already closed.
What's in the pack
Change Policy
What counts as a change, the three severity categories, and the hard rule against deleting a field unchecked.
Release Note Format
The fixed five-field format that carries the dependent list forward from the assessment instead of leaving it in another sheet.
Rollback Procedure
A different path for each change type, plus the 15-day window Salesforce actually gives you to recover a deleted field.
Change Request Queue
Every proposed change logged with who asked, what they want to touch, and why they believe it is safe.
Impact Assessment
Each request checked against your live report and automation inventory, naming the actual dependent instead of guessing.
Release Log
What shipped, why, and the dependent list from the assessment, carried forward for the next incident.
How it works
- 1
Send the inputs
Your field dictionary or a field export, plus a list of active reports, dashboards, automations that might read them, and, if you have it, which system is supposed to own each field.
- 2
Every change gets logged
Whoever is proposing a change, what they want to touch, and why they believe it is safe, filed in the Change Request Queue.
- 3
The impact gets checked
Anything that deletes, retypes, or repurposes a field is run against the report and automation inventory before approval, not against memory.
- 4
The release carries it forward
What shipped, why, and every dependent the assessment found, copied into the release note so a later incident starts from a known list.
Frequently asked questions
What counts as a change here, versus routine CRM use?
Anything that alters a field already in production use: a delete, a retype, a repurposed picklist or lookup, plus page layouts, validation rules, and automations already relied on. A brand-new, optional field nothing else references yet is the lightest case and clears fast.
How is this different from a generic change-request template?
A generic template's Impact Assessment is a textarea: write down what you think might break. This pack's Impact Assessment runs the proposed change against your actual report and automation inventory and names the specific dependent, or finds none, instead of asking anyone to remember.
What happens when a request finds a live dependent?
It becomes a Major change, and it needs sign-off from the CRM admin plus the owner of each dependent report or automation the assessment named, not just the requester's manager. A request with no live dependent clears same day as Standard.
Can a deleted field actually be recovered?
For 15 days. A deleted custom field moves to a separate Deleted Fields section rather than the standard Recycle Bin, recoverable with its data intact until that window closes, after which the field and its history are gone for good.
We already run a formal change advisory board. Do we need this?
Probably not as built. This pack is sized for a CRM admin team of one to a handful of people, whose prior state was usually no written record at all. It is not a replacement for an existing ITIL process with its own severity matrix and sign-off chain.
We don't have a report and automation inventory yet. Where do we start?
A field dictionary names every field and who would notice it gone, and a permissions and access review covers who can even execute a change safely. Either output feeds straight into this pack's intake process.
What format are the downloaded files?
Word (.docx) for the three documents, CSV (.csv) for the three sheets, zipped together and needing no conversion. Excel, Numbers, and Google Sheets open the sheets directly, and the format documents open in Word or Pages.
Find out which proposed changes are actually safe
Send your field dictionary or export and a list of your active reports and automations, and see which proposed changes have a live dependent nobody named.
Edit with AI