On this page (8)
When your Salesforce administrator leaves, secure access first, then find everything that runs under their user account, then capture what only they knew. Freeze their user rather than deactivating it immediately, because integrations, scheduled jobs and automation may depend on it. Arrange interim coverage before requests start piling up.
Day one: access and security
- Freeze the departing admin’s user so they cannot log in, without breaking anything that references the user.
- Confirm at least one other person has System Administrator access and multi-factor authentication set up.
- Review who else has admin rights, and remove any that are no longer needed.
- Rotate any shared credentials, API keys or integration passwords the admin knew.
- Check connected apps and login history for anything unexpected.
Week one: what runs as that user
| Item | Why it matters | What to do |
|---|---|---|
| Integrations | Many connect using the admin’s login | Move them to a dedicated integration user |
| Scheduled jobs and Flows | They may run as, or be owned by, the admin | Reassign ownership and confirm they still run |
| Report subscriptions and dashboards | Dashboards can run as a specific user | Reassign the running user |
| Default and automated users | Some settings name a specific user for automated records and emails | Update settings before deactivating |
| Assignment and approval rules | Records may route to the admin | Route to a queue or another owner |
Only deactivate the user once nothing depends on it. Salesforce will block deactivation in some cases where the user is still referenced, which is a useful safety check but not a complete one.
Capture what they knew
- A list of open requests and half-finished work.
- Why key automation and custom code exist, not just what they do.
- Integration details: endpoints, schedules, error handling and who to call.
- Known problems and workarounds users rely on.
- Upcoming renewals, releases and projects.
Interim coverage
Requests do not stop when an admin leaves. A managed services partner can start with a health check to learn the org, cover day-to-day requests while you hire, and stay on afterward for development, integrations and release reviews if that helps.
What should the first 30 days look like?
Split the first month into three short phases: contain the risk, map the org, then hand it to its next owner. Each phase has a clear finish line, so nothing waits on a new hire.
| Period | Focus | Done when |
|---|---|---|
| Days 1–3 | Lock down access and triage urgent user requests | Two named people can administer the org safely |
| Days 4–10 | Find every job, integration and rule tied to the old user | Each item has a new owner or a dedicated user |
| Days 11–20 | Write down the org: objects, automation, integrations, packages | A new admin could read it and find their way around |
| Days 21–30 | Pick the long-term model and move the request queue to it | Requests have one front door and a response owner |
What documentation should survive any admin?
Keep a living org map that explains purpose, not just configuration. Store it in a shared space the company owns, never in one person’s drive or inbox.
- An object list with the business process each custom object supports.
- An automation register: every Flow, trigger and scheduled job, its object, and its business owner.
- An integration sheet naming the connected system, the Salesforce user it runs as, and who to contact when it fails.
- A release log recording what changed, when, why and who asked for it.
- A list of managed packages with their vendors and renewal dates.
- A short guide to the sandbox strategy and how changes reach production.
Should you hire a replacement or move to managed services?
Hire when the request volume fills a full-time role and the work stays within one skill set. Choose managed services when needs are uneven or span admin, development and integration work.
- Ask how many requests arrive each month, and how many need a developer or integration skills.
- Ask whether one person could cover every cloud and package you use today.
- Ask how long the org could cope during a slow hiring process.
- Ask who would review a new admin’s changes before they reach production.
Our guide to managed services vs. hiring a Salesforce admin compares the two models in more detail, including the hybrid option.
What if the admin is still working their notice?
Use the notice period for recorded walkthroughs, not new projects. Knowledge transfer is far easier while the person can still answer questions.
- Pause new build work so the admin can focus on handover.
- Record screen-share sessions on each integration, key Flow and any custom code.
- Have the admin fix or document open errors in the debug and email logs.
- Ask them to list every login, vendor portal and support account they hold.
- Pair them with the person or partner taking over for the final handover sessions.
Questions people also ask
What happens if our only Salesforce admin leaves?
Your org keeps running, but anything tied to the admin's user account is at risk. Integrations, scheduled jobs, Flows, dashboards and approval rules can all depend on that user, so freeze it rather than deactivating it right away. Confirm another person has System Administrator access with multi-factor authentication, rotate shared credentials, and arrange interim coverage before requests pile up. A managed services partner can learn the org through a health check and cover requests while you hire.
Our Salesforce partner left and nobody can support what they built. What now?
Treat it like an admin departure: secure access first, then find everything that depends on their users, then write down how the org works. Confirm someone at your company holds System Administrator access, rotate any credentials they knew, and move integrations onto a dedicated integration user. Reassign scheduled jobs, Flows and dashboards that run as their accounts. A new partner can start with a health check to learn the org and cover day-to-day requests.
How do we document a Salesforce org nobody understands?
Build a living org map that explains why things exist, not just how they are configured. List each custom object and the process it supports, every Flow, trigger and scheduled job with its business owner, each integration with the user it runs as and who to call when it fails, and your managed packages with renewal dates. Store it in a shared space the company owns, never in one person's drive or inbox.
