A colleague leaves, someone removes the account, and the team discovers that a useful file or automated task belonged to that person. Avoid that order. First identify the resources the account controls, give each one a continuing custodian, and verify that the next person can do the actual job.
Access, ownership, and responsibility are different. A colleague may be able to open a document without owning it, or edit an automation without being able to maintain its connected accounts. Your handover needs to cover all three.
List the resources that matter to ongoing work
Ask the departing colleague and the people who receive their work to name the current deliverables and repeating tasks. Start with active client projects, shared templates, recurring reports, form responses, and scheduled workflows. Use the team’s existing file and automation registers where they exist.
Create one row per resource or meaningful group. Record its link, actual technical owner, continuing responsible person, required permissions, connected identity, and verification result. Keep credentials in the approved credential store; the register should contain a reference, never a secret.
| Resource | Technical control | Continuing responsibility | Acceptance check |
|---|---|---|---|
| Client delivery document | Individual file owner or organization-managed storage | Named project lead | Open and edit the actual file |
| Recurring workflow | Workflow owner and connected accounts | Named automation maintainer | Inspect the workflow and perform an appropriate safe check |
| Reporting output folder | Folder and relevant file permissions | Named reporting lead | Open existing output and confirm the intended destination |
If a row has no agreed recipient, resolve that before account removal. “The team” is not a person who can accept a handover.
Confirm file ownership, not just folder access
Google Drive’s ownership guide distinguishes transferring a folder from transferring the files inside it. Changing the folder owner does not change those file owners. Work or school accounts also have organization-specific transfer boundaries.
Check the actual files needed for current work. Where a supported ownership transfer is appropriate, follow the account’s documented route and confirm the new owner afterward. For organization-managed shared storage, involve the administrator and verify its actual storage model rather than treating everything as an individually owned My Drive file.
Avoid moving a whole client folder into a different sharing boundary merely because that is quicker. Check the intended destination and recipients first. The handover should preserve appropriate access to the work, not broaden access to unrelated material.
Treat automation connections as a separate handover
Opening a workflow is only part of maintaining it. Identify which account supplies its email, storage, database, or other connection. Also note where results go and who receives failure alerts.
n8n’s workflow-sharing documentation describes ownership, editor access, and credential permissions separately. Do not assume that sharing a workflow transfers ownership or gives its editor full control over every credential. Use the supported controls for your installed version and plan, with an administrator where required.
Check each important workflow with its recipient. Can they inspect the steps, understand its schedule, locate the approved credentials, and respond to a failure? A test must be safe for that workflow: use a test input or controlled destination rather than sending an accidental client email. Record configuration-only verification honestly when a live check is inappropriate.
Use a concrete acceptance record
Fictional example: Morgan owns a monthly delivery report and maintains the workflow that places it in a shared folder. Priya accepts reporting responsibility. She opens the relevant files, confirms their ownership arrangements, and inspects the workflow with the administrator. They discover that the connection still uses Morgan’s account. That connection needs a supported replacement before the account-removal task can proceed.
Record what was verified and what remains open. A useful entry is “Priya opened the delivery report; workflow connection still requires replacement by administrator.” “Everything shared” hides the remaining dependency.
Remove the account after acceptance
Have the responsible administrator review the completed register before the scheduled removal. Follow the organization’s separate account, access, and retention procedure. This guide does not replace those policies or establish that every third-party resource has been found.
After the change, check the next relevant scheduled task and its output. If a dependency was missed, stop the affected task safely and use the recorded resource links to diagnose it. Keeping a short, verified handover gives the next person a practical starting point rather than a search through a former colleague’s account.