SkyPlanner 
When a Salesforce admin hands in their notice, the org keeps running. Nothing breaks on day one, and that is exactly the problem. A Salesforce admin handover usually gets two weeks and a document, and the document is almost always a description of the configuration.
Salesforce already records the configuration. What it does not record is what the admin knew. That is what goes missing, and it shows up months later, when somebody needs to change something and nobody can say why it is the way it is.
This is what we write down instead, how we fit it into a two-week notice period, and what we do when there is no successor at all.
The org already documents the what
Setup tells you what every custom field, flow, validation rule and permission set is. Fields carry descriptions and a view of where they are used. Flows keep their versions. The Setup Audit Trail records who changed what and when, for roughly the last six months. A handover that copies all of this into a document produces something long, out of date within weeks, and read by nobody.
What none of it records is the reason. The audit trail can tell you a validation rule changed in March. It cannot tell you it changed because finance stopped accepting quotes without a purchase order number, or that the change was only ever meant to last until the end of the quarter.
So the rule we work to is simple: if Salesforce can tell you, do not write it down. Write down what only the person leaving can tell you.
Five things only the admin knows
1. Why decisions were made, including the ones that were rejected. Why the custom field exists when a standard one looks like it would do. Why opportunities are split the way they are. Why one team has its own record type. And, most of all, the options that were considered and dropped. Nobody writes those down, and they are the ones the next person rediscovers the expensive way: three weeks building the obvious approach before finding out why it was never used here.
2. What each automation assumes. Every flow carries a belief about how the business runs. That every account has an owner in the right territory. That discounts above a certain level always go to the same approver. That renewals are created a fixed number of days before the end date. When the belief stops being true, the flow keeps running anyway, and nothing errors. The admin usually knows which of those assumptions are already shaky. Write those down first.
3. What depends on things outside Salesforce. The integrations, and the users they run as. Who to call at each vendor when a sync stops. The scheduled jobs and exports that somebody downstream relies on without ever having seen them. Where the credentials are kept, which is a location, never the credentials themselves in the document. If you need a starting list, the integration users and API callers we looked at in the Winter ’27 release updates that decide AI readiness are usually most of it.
4. The calendar. The work that happens only a few times a year, which is exactly why nobody else knows it exists. Release updates, three times a year, each with changes enforced on a date. Sandbox refreshes, and what has to be fixed afterward before anyone can test again. Certificates, integration passwords and connected app secrets that expire quietly. People who leave, whose records, scheduled reports and dashboards still point at them. The renewal, with its license counts and the add-ons nobody uses. Each of these is invisible until it is late.
5. The people and the workarounds. Who asks for what, and through which channel, because the real request queue is rarely the official one. Which three reports leadership actually opens. Which team uses a field for something it was never designed for. The spreadsheet that sits next to the official process and quietly is the process. Most teams run two versions of every process, the documented one and the real one, and the admin is usually the only person who knows both.
A handover is a test, not a document. The only proof that it worked is somebody else doing the job from it.
A format that keeps each entry short
Long handover documents fail because nobody can find the one thing they need in them. Every entry in a Salesforce admin handover can follow the same five short lines, and an entry that does not fit in five lines is usually two entries.
What: the field, flow, integration or task, named the way it appears in Setup.
Why: the reason it exists, in one or two sentences.
Rejected: what else was tried or considered, and why it did not work here.
Owner: the role that decides if it changes.
Watch for: the assumption that would make it wrong, or the date it next needs attention.
The last line is the one that earns its place. “Watch for: assumes every account has a territory owner” tells the next person exactly which reorganization will break the flow. “Watch for: certificate expires in March” puts the entry straight onto the calendar.
How we run a handover in a two-week notice period
Two weeks is enough, as long as nobody spends them rewriting what Setup already shows. This is the shape we use.
Days one and two: the inventory. Sit down with the person leaving and list what falls under each of the five headings. For every item, note two things: how fragile it is, and who will own it afterward. Write the owner as a role, not a name. “Sales operations” survives the next resignation; a person does not, which is the same reason we recommend naming field owners as roles when you check data readiness for AI.
Days three to eight: recorded walkthroughs. One session per heading, thirty to forty-five minutes each, with the screen recorded and the successor, or whoever is covering, in the room. Recording is cheaper than writing and keeps the reasons in the words of the person who made the decisions. The document becomes an index: one line per item, the owner, and a link to the minute in the recording where it is explained.
Days nine and ten: the test. The successor does one real, routine task from each heading using only what was written down and recorded, while the person leaving watches and says nothing until it is over. Add a picklist value and follow it through every flow, report and integration it touches. Deactivate a test user cleanly. Read the next release’s updates and say which ones apply. Every place the successor gets stuck is the next paragraph to write, and there is still time to write it.
The last day: access. Make sure at least one other person already holds full administrator access well before the last day, not on it. Then freeze the departing admin’s account rather than deleting anything, reassign what they own, and deactivate it once the scheduled jobs, reports and approvals that depended on it have moved.
No successor yet?
Ongoing support can cover the calendar and the day-to-day requests while you hire, and the handover becomes the brief for whoever comes next.
When there is no successor at all
In a lot of mid-sized companies there is one Salesforce admin, and when that person leaves the role stays open for months. The handover then has nobody to hand over to, and the risk is not the first week. It is the slow drift that follows.
Four things keep that drift small. Decide who holds administrator access in the meantime, and make it two people, so nothing depends on one login. Hold configuration changes to what is genuinely urgent, so nobody improvises in an org they do not know. Put the calendar into a shared calendar with a role against every entry, so the release updates and the expiring credentials still get attention. And keep a running log of every question somebody asks that nobody can answer. After a month, that log is the most accurate job description you will ever write, and the best brief for a new admin or a partner.
Where it should live
Not in a wiki nobody updates. One shared document, kept somewhere people already look, with the recordings linked from it. The meaning of individual fields belongs closer to the work, in field-level help text, where the person filling in the field sees it and so does anyone who reads it later.
And it needs a moment to be reviewed, or it decays like everything else. The natural one is already on the calendar: three Salesforce releases a year. When somebody reads the release updates for your org, somebody also opens the handover document and fixes whatever has stopped being true. It takes an hour, and it means the next handover starts from a document that is still right.
Why it matters beyond the next resignation
Everything above is ordinary admin work, and none of it depends on AI. It is worth noticing, though, that the same gap shows up when an assistant is connected to the org. It can read the configuration in seconds. It cannot read the reasons, because they were never written anywhere. An org where the reasons are written down is easier for the next admin, for a partner arriving cold, and for any tool that has to work from what is actually recorded.
Our view
Handovers rarely fail loudly. They fail politely: a long document, a friendly last week, and a problem that arrives four months later for somebody who was not in the room. A Salesforce admin handover does not need more pages to avoid that. It needs fewer, aimed at what only the person leaving knows, and one honest test before the last day.
If you do one thing from this article, make it the test. Pick a routine task, hand the successor what was written down, and watch where they stop. That is the handover, and it is the part most teams never get to.
