Your Only Dynamics 365 Administrator Has Resigned: A 72-Hour Knowledge Capture Plan

The week your only Dynamics 365 administrator resigns, work in three blocks while their access still exists. Hours 0 to 24: confirm two other people hold the admin roles, then export the solutions, flow definitions, security role matrix, plug-in registrations and scheduled job list. Hours 24 to 48: find every connection, flow, app registration and service principal that runs as or belongs to the leaver, and reassign each before their account closes. Hours 48 to 72: have them record a walkthrough of each critical process. Before they go, test whether you can run without them by having someone else make one real change in a sandbox and deploy it. Then spend thirty days spreading the knowledge across two people.

This plan is specific to a Dynamics 365 Customer Engagement and Power Platform administrator. The general method for handing over any business-critical app, including source code, runbooks and proving the handover, is in our guide to handing over a business-critical app before its maintainer leaves, and it is not repeated here.

What should you do in the first hour after your Dynamics 365 administrator resigns?

Protect access before anything else, and do not touch their account. The instinct to disable a leaver's account on notice is exactly what breaks Dynamics 365 estates, because flows, integrations and scheduled jobs often run as that person.

1. Check who holds Global Administrator, Power Platform Administrator and System Administrator in each environment, including sandboxes. If the leaver is the only holder of any of them, add at least two people from your own organization today.
2. Tell IT and HR in writing that the leaver's account must not be disabled, deleted or have its licence removed until the administrator inventory below is finished. Blocking sign-in comes last, and deletion later still.
3. Confirm the last working day and book time with the leaver for each of the three blocks below. Explain that this is about protecting the system, not about them.
4. Freeze non-urgent changes to production until they have gone, so nothing new is built that only they understand.
5. Name the successor, or the two people who will share the role, so that the recordings and the test change have someone to drive them.

What must you export in the first 24 hours while access still exists?

Everything that describes how the system is built, from the environments themselves, into a repository or secure location your organization owns. The environment is the source of truth; any documentation the leaver has is useful but secondary.

• Solutions. Export every unmanaged solution from the development environment, ideally unpacked into source control with the Power Platform CLI, and record every managed solution in production with its publisher and version. Note anything customized directly in production outside a solution. The unpacking steps are in our Power Platform ALM guide.
• Flow definitions. Export every cloud flow, including personal flows that sit outside solutions and that only their owner or an administrator can see, and list desktop flows and the machines they run on.
• Security role matrix. Business units, security roles and their privileges, teams, field security profiles, and which users hold which roles, with every System Administrator named. There is no single built-in export, so use a community tool or a short script against the Web API, and have the leaver explain any role that was created as a one-off.
• Plug-in registrations. Every assembly, step, message, table, stage, mode, rank and image, custom APIs, and where the source code for each assembly lives. If the source is only on the leaver's machine, getting it into your repository is the most urgent task of the whole week.
• Scheduled and recurring jobs. Recurring system jobs such as bulk deletion and duplicate detection jobs, scheduled cloud flows, recurring classic workflows, data exports and imports, and anything outside Dynamics 365 that runs on a schedule against it, such as Azure functions, integration jobs or report refreshes.
• Configuration the solutions do not carry: environment variable values, queues, mailbox configuration, templates and reference data.

If the environment turns out to be badly documented, the fuller reverse engineering method is in our guide to taking over an undocumented Dynamics 365 environment.

Which connections and service principals must be reassigned before the account closes?

Anything that authenticates as the leaver, or that only the leaver can manage. Spend hours 24 to 48 finding and moving these, with the leaver present, because some cannot be recovered cleanly afterwards.

• Power Automate connections created by the leaver, and the flows that use them. Connections belong to the identity that signed in and cannot simply be transferred, so each one has to be recreated under a service account or service principal and the flows re-pointed. The recovery order, the admin rights needed and how to list every flow that depends on one person's connections are answered in the Power Automate FAQs on our Power Automate consulting page.
• Flows and classic workflows owned by the leaver. Add a second owner or change the owner to a team or service account, and check which classic workflows would fail once the owner is disabled.
• Entra app registrations behind integration application users. Check who is listed as owner, add owners from your organization, and record every client secret and certificate with its expiry date. Assume any secret the leaver has seen needs rotating in a planned change before they go.
• Service principals and application users used by integrations, pipelines and tools. Confirm what each one is for and who in your organization now owns it.
• Deployment pipelines. Service connections, personal access tokens and variable groups created under the leaver's account in Azure DevOps or GitHub.
• Reports and data connections. Scheduled Power BI refreshes, gateways and data exports that use the leaver's credentials.
• Records and queues owned by the leaver in Dynamics 365. Reassign them to a successor or team so work does not stall and ownership-based security still behaves.
• Notifications. Service health, admin center, licence and billing messages, and failure alerts that go only to the leaver's mailbox. Point them at a shared mailbox.

Keep the account and licence active until everything on this list has been moved and tested, then block sign-in, watch run histories and integration logs for a week, and only then remove the licence and account.

What recorded walkthroughs should you demand for each critical process?

One short recording per critical process, made in hours 48 to 72, with the successor sharing their screen and driving while the leaver explains. Recordings the leaver narrates alone are watched once and forgotten; recordings where someone else does the work expose the gaps.

List the critical processes first, meaning those whose failure the business would notice within a day, such as lead or case routing, quote and order creation, work order scheduling, integrations with finance or the website, and the monthly or yearly jobs. Then, for each one, the recording should cover:

1. What triggers it and which users start it.
2. Which components run, in order: forms and scripts, business rules, plug-in steps, flows, integrations.
3. What typically goes wrong, how the leaver notices, and exactly what they do to fix it.
4. Any manual step they perform so the process appears to work.
5. What must not be changed without understanding something else first.

Add one recording for the administrator's calendar: release wave preparation, licence and capacity checks, secret and certificate renewals, user onboarding and offboarding, and anything done at month end or year end. Store the recordings next to the exports, with a written index, and have the successor write questions into the same place as they arise.

How do you test whether you can run Dynamics 365 without them?

Before the leaver's last day, have someone else attempt one real change in a sandbox and take it through your release path, with the leaver watching but not touching. Pick a change the business actually wants and that touches more than one layer, such as adding a column to a form and a flow that uses it, or adjusting a security role.

The successor makes the change in development, adds it to the right solution, exports or builds it, deploys to a test or sandbox environment, checks it works and that nothing else broke, and explains how they would roll it back. Every question they have to ask is a gap in the exports, the recordings or the runbooks; fix it and repeat the step.

If they cannot complete the change at all, you have learned the most important fact of the week while there is still time to act on it: you will need interim senior cover from the day the leaver goes, not after the first incident.

What should the thirty-day plan look like so this cannot happen again?

The goal is that at least two people can administer and change the system, and that nothing runs as a named employee.

1. Week 1: name the two people who will share the role, internal or external, give both the admin roles they need, and put the exports and recordings in a repository both can reach.
2. Week 2: make source control and a repeatable deployment path the only way changes reach production, so the release process no longer lives in one head.
3. Week 3: move every remaining production flow and integration onto service accounts or service principals, and give every flow a second owner.
4. Week 4: swap roles. The second person performs a real release and handles the next incident while the first reviews, and both update the runbooks from what they learned.

After that, keep three standing rules: at least two named holders of every admin role, no production connection authenticated as an ordinary employee, and a quarterly check that the inventory still matches the environments.

What if your Dynamics 365 administrator has already left?

Then the order is the same, but you work from the environment rather than from the person. If nobody in your organization holds Global Administrator any more, recovering administrative access comes first, and the route through Microsoft is described in our guide to switching Dynamics 365 partners safely. If their account still exists, do not delete it: reassign what runs as it first. The first-days sequence for a system nobody can explain, including locking down change and taking back the keys, is on our Dynamics 365 project rescue and takeover page. And if they are reachable, ask for one paid hour with a prepared list of questions; it is usually the cheapest hour of the whole recovery.

How do you cover the gap until a replacement is in place?

Hiring an experienced Dynamics 365 administrator usually takes longer than a notice period, so plan interim cover rather than hoping nothing breaks. The most useful cover overlaps with the leaver, runs the test change with the successor and holds the runbooks until the permanent arrangement is in place. How that works as staff augmentation, including how the knowledge is kept when the cover ends, is on our Dynamics 365 staff augmentation and subcontracting page.

Solzet provides that cover with senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, for your team directly or white-label for Microsoft partners. We do not cover Dynamics 365 Finance, Business Central, NAV or Finance and Operations administration. Do not decide the platform question during a handover; if, once someone else understands the system, it turns out Microsoft licensing never fitted how it is used, a custom CRM is an option to price then.