Salesforce change management is the routine that takes a change from a request to production and leaves a record of what happened. For an admin or a small team, it comes down to seven checks: write the request down, size the risk, build in a sandbox, test, get a sign-off, deploy with a rollback plan, and log the result.
This checklist is written for orgs with one admin or a handful, and no dedicated release manager. It covers configuration changes such as fields, flows, validation rules, page layouts and permission sets, plus the Apex that sometimes travels with them. It leaves out user training and adoption, which deserve a process of their own. If you also want an AI client to take over some of the building and documenting, the Cirra AI page for Salesforce admins shows how admins use it while they keep the judgment calls.
The checklist at a glance
Each stage has one question to answer and one thing to keep as evidence. The sections after the table explain each stage and give a change record you can copy.
| Stage | What to confirm | What to keep |
|---|---|---|
| 1. Intake | The request names a requester, a business reason and a needed-by date | One row in your change log |
| 2. Impact and risk | You know what depends on the component and have assigned a risk tier | The risk tier and your dependency notes |
| 3. Build | The change exists in a sandbox, with names and descriptions that follow your standard | The sandbox name and the list of components |
| 4. Test | You tested it as the people who will use it, with good input and bad input | Short test notes |
| 5. Approve | Someone signed off and the deployment window is set | The approver and the deployment window |
| 6. Deploy | Validation passed and the rollback steps are written | The deployment time and the rollback steps |
| 7. Review | A smoke test passed in production and the log row is closed | The closed change record |
Step 1: Write the request down
A request that lives in a chat thread or a hallway conversation cannot be tracked, prioritized or reversed. Capture five things for every request: who asked, why the business needs it, what should change, which objects or processes it touches, and when it is needed. A shared spreadsheet is enough for a small team. If your business teams already send work through tickets, keep the ticket as the record and add the same five fields to it.
Ask about the problem behind the request. A request for a new field is often a request to see a value on a page, and a layout change or a report might solve it with less to maintain. A few minutes of questions at intake can remove a change from the queue entirely.
Step 2: Check the impact and assign a risk tier
Before you edit an existing field, flow or validation rule, find out what references it. Flows, validation rules, formula fields, page layouts, reports, Apex classes and integrations can all depend on one component, and many admins learn about a dependency from an error message after the deployment. Write what you find in the change record, even if the answer is that nothing depends on the component.
Automation on the same object deserves a second look. Salesforce's Flow Trigger Explorer, which you can open from the Flows page in Setup, lists the record-triggered flows on an object and lets you view their versions, so you can see what already runs when a record is created or updated before you add another flow.
Then assign a risk tier. The tiers below are a starting point. Adjust the examples to your org, and keep the number of tiers small enough that you will use them.
| Risk tier | Examples | Process |
|---|---|---|
| Low | Help text, a picklist label, moving a field on a page layout | Build in a sandbox, run a quick check, log it. You can approve it yourself. |
| Medium | A new custom field, a new validation rule, a new screen flow | Build in a sandbox, test as a target user, and have the requester sign off on the result. |
| High | Edits to an existing record-triggered flow, permission sets or sharing, Apex, anything that touches many records or an integration | Full test plan, a second reviewer, a scheduled window and a written rollback plan. |
| Emergency | Production is broken or users are blocked | Fix first in the fastest safe way, write the record within one business day, and copy the fix back to the sandbox. |
Step 3: Build in a sandbox and name things so you can find them
Build in a sandbox and use production only to deploy finished changes. A sandbox is a copy taken at one point in time, so changes made in production after the copy do not appear in it. If your sandbox is old, refresh it before you start a High tier change so you are testing against what production looks like today.
Give every new field, flow and rule a description, and follow a naming standard that tells the next admin what the component is for. Keep each change small enough to deploy and reverse on its own. When you bundle an unrelated fix into the same deployment, a rollback of one change drags the other along with it.
Step 4: Test the change the way users will meet it
Administrators can see and edit nearly everything, so a test run under your own login proves little. Test with a user who holds the same profile and permission sets as the people who will use the change. Then run four kinds of checks:
- Expected input. Create or edit a record the way a user would and confirm the result.
- Bad input. For a validation rule, confirm that it blocks the bad record and lets the good record through. For a flow, try a record that meets none of the entry conditions.
- Neighbors. Check the other automation on the same object, since two flows or a flow and a trigger can interact in ways neither one shows alone.
- Volume, when it matters. If the change touches many records at once, test it in a sandbox that holds a realistic number of them.
For flows, Flow Builder's Debug button lets you run a flow against a record before you roll it out. For Apex, Salesforce runs tests as part of a production deployment. According to Salesforce's Metadata API documentation on quick deploy, a deployment that runs all tests or all local tests needs at least 75% Apex code coverage across the org, and Apex triggers need some coverage. Write your test results in two lines in the change record: what you tried and what happened.
Step 5: Get sign-off and pick a window
Match the approver to the tier. The requester signs off on Medium changes after seeing the result in the sandbox. A High change benefits from a second pair of eyes on the change record, from another admin or a consultant. If you work alone, wait one business day and read your own record again before you deploy. Problems that were invisible while you were building often show up on a second read.
Pick a window that the requester's team can live with. Ask when they cannot afford a surprise, such as month-end close or the last week of a sales quarter. Watch Salesforce's own calendar too. Salesforce publishes release notes, a sandbox preview schedule and a maintenance calendar for each release, and its Winter '27 release countdown for admins recommends checking the Release Updates page in Setup for items that need action. Avoid deploying a High tier change in the days around your instance's upgrade.
Step 6: Deploy with validation and a rollback plan
Pick the deployment path your team can run reliably. In SF Ben's 2026 Salesforce Admin Survey, Change Sets were used by over 41% of respondents and were described as the dominant deployment method across the ecosystem (Top 10 Insights from SF Ben's Mega 2026 Salesforce Admin Survey, June 2026). Change sets suit a small team, as long as you plan around what they cannot do: they have no rollback feature, and a change set that has been uploaded cannot be edited, so a missed component means cloning the set and uploading it again.
Whatever path you use, validate before you deploy. A validation-only deployment runs the checks and the Apex tests against production without saving the change. Per Salesforce's documentation, a successful validation can be quick deployed without running the tests again, as long as the quick deploy happens within 10 days of the validation. In a change set, that is the Validate button followed by Quick Deploy.
Check three details before you press the button:
- Include the permission sets or profile changes that grant access. A new field stays invisible to users until field-level security says otherwise.
- List the manual steps that the deployment cannot carry. Some settings, such as standard picklist values, cannot travel in a change set and have to be created by hand in production.
- Write the rollback steps in the change record before you deploy. Since change sets cannot be undone, your written backout steps are the rollback.
A rollback plan by component type
The right backout depends on what you changed. The table lists the fastest option for common components.
| Component | Fastest backout | Watch for |
|---|---|---|
| Flow | Open the flow in Setup, find the previous version in the version list, and activate it (the version list is also in Flow Trigger Explorer) | Records created while the new version was active keep whatever it did to them |
| Validation rule | Deactivate the rule | Records saved while the rule was off were never checked against it |
| Page layout or record page | Reassign or reactivate the previous layout, which is why you clone before editing | Clone first. You cannot restore a layout you did not copy. |
| Permission set | Remove the assignment, or restore the previous settings from your notes | Save the old settings in the record before you change them |
| Custom field | Hide it from layouts and remove field-level access instead of deleting it | Deleting a field puts its values at risk, so export them first |
| Apex class or trigger | Deploy the previous version from your saved copy | You need the old code in version control or a saved file |
| Bulk data update | Reload the values from the export you took before the update | Take the export before the update, not after |
Step 7: Smoke test, log the change and review the audit trail
Right after the deployment, run a short smoke test in production with a user account that matches the people affected, and check that the new field, flow or rule behaves as it did in the sandbox. Watch for flow error emails over the next few days (by default they go to the last person who modified the flow), then close the row in your change log with the date, the person who deployed and the outcome.
Salesforce also keeps its own record. The Setup Audit Trail logs changes made in Setup, and you open it by typing View Setup Audit Trail into Quick Find in Setup. The page shows the 20 most recent changes, and you can download a CSV file covering up to the last 180 days. It has limits: for page layouts and Apex classes, the trail shows that a change happened but not what the change was. Keep it beside your own change log, and keep code in version control.
Use the two records together. Once a month, download the audit trail and compare it with your change log. An audit trail entry with no matching log row is an unlogged change, and finding out who made it and why is an inexpensive governance check that a small team can run.
A copy-ready change record
Paste this into a spreadsheet row, a ticket template or a document. It holds the fields from the stages above, and each line takes a short answer.
CHANGE RECORD
ID: CHG-0001
Requester:
Business reason:
Change summary:
Components touched:
Risk tier: Low / Medium / High / Emergency
Built and tested in (sandbox name):
Dependencies checked:
Test notes (expected result, bad-input result, neighboring automation):
Approver and date:
Deployment window:
Deployment method:
Manual steps after deploy:
Rollback steps:
Smoke test result:
Closed on:Where Cirra AI fits in this checklist
Cirra AI is a hosted Salesforce Admin MCP Server. You authenticate a Salesforce org through OAuth, connect the AI client you already use, such as Claude, ChatGPT or Cursor, and describe the change you need. Cirra AI makes it as the connected user, within that user's permissions. Cirra AI supports Salesforce Enterprise Edition and up, and the Free plan includes 100 credits.
Several stages of the checklist map onto that workflow. In the impact stage, you can ask your AI client how an existing flow is built or who has access to an object before you edit anything. In the build stage, you can connect a sandbox and have the change built there, then review it. By default, Cirra AI shows you each change it plans to make before it runs, and actions are logged in an exportable audit trail that you can set beside your change log.
Access settings carry the governance side. On the Salesforce Admin MCP Server product page, Cirra AI describes four data categories (Metadata, User Data, Personal Setup Data and Business Data) that you can set independently to None, Read Only, or Read and Write. A sandbox connection can allow metadata changes while the production connection stays read-only for metadata. Cirra AI does not promote changes from a sandbox to production for you, so deployment still follows your own process from Step 6. The checklist for letting AI change your org lists five checks to run before you give any AI tool write access, and the org documentation use case shows how Cirra AI helps keep the records current.
Salesforce can change its tools, limits and release dates, so check the current documentation and try each step in a sandbox before you rely on it. Ready to try it on a sandbox? Start Free Trial, or Learn More about how admins use Cirra AI.
Frequently asked questions
What is change management in Salesforce?
Salesforce change management is the process that takes a change to your org from a written request to production and records what happened. It covers intake, impact checks, building and testing in a sandbox, approval, deployment, rollback planning and a change log.
Do I need a change management process if I am the only admin?
Yes, and a short one is enough. A solo admin is the only person who remembers why a field or flow exists, so a one-line request record, a sandbox test and a change log protect your future self and whoever inherits the org.
Can you roll back a Salesforce change set?
No. Change sets have no rollback feature, and an uploaded change set cannot be edited. Write the backout steps for each change before you deploy, such as reactivating the previous flow version or deactivating a validation rule.
How long does the Setup Audit Trail keep history?
The Setup page shows the 20 most recent changes, and you can download up to the last 180 days as a CSV file. Download it on a schedule if you want a longer record.
How should I handle an emergency change in Salesforce?
Fix the problem first in the fastest safe way, then write the change record within one business day. Copy the fix back into your sandbox so the next refresh or deployment does not undo it.
Can AI make Salesforce changes inside a change management process?
Yes. Cirra AI connects an AI client such as Claude, ChatGPT or Cursor to your Salesforce org through OAuth and makes changes as the connected user, within that user's permissions. Connect a sandbox, review each planned change, and deploy to production through your usual process.
