When someone leaves a small store, two things walk out with them: their logins and the steps only they knew. The checklist has to handle both, in the right order.
Hand things over first, then switch things off. Record the processes only the leaver knows while they still work there. Move anything they own to someone else. Then close access on the last day, starting with the Shopify admin, and suspend accounts rather than deleting them.
The order matters because some of the switches cannot be undone. Removing a user from Shopify is permanent. Deleting a Google Workspace account deletes whatever that person owned and nobody transferred. Get the sequence right and neither of those can hurt you.
The other half of this. Offboarding is your onboarding access list read backwards, which only works if that list was written down.
Offboarding is two different jobs, and they run on different timetables.
| Job | When it happens | What goes wrong if you rush it |
|---|---|---|
| Knowledge handover | During the notice period, while the person still does the work | A process nobody else has run is lost the day they leave |
| Access teardown | On the last working day, scheduled in advance | A login stays open for months because nobody remembered it existed |
Squeeze both into the last afternoon and both are done badly. The handover becomes a hurried tour of the laptop. The teardown becomes whatever the owner remembers at five o'clock.
Start with the work that only exists in the leaver's head. Two questions sort it quickly. Has anyone else ever run this end to end? And what does it cost if it goes wrong once?
A monthly task nobody else has touched beats a daily task three people share. The monthly one is where the loss lives: the stock reconciliation, the wholesale invoice run, the way they handle the one supplier who always ships short.
Record those tasks while the person actually does them. Not a written summary on their last day. A written summary is their memory of the process, filtered through what they think matters. A recording is the process itself, including the step they no longer notice doing.
Someone rushing through a task while their laptop is being packed skips the exceptions and shows a tidier version than the real one. Record mid-notice-period, on a day the task genuinely needs doing.
How to find the workarounds that never made it into the official version, before the person who invented them leaves.
Then move ownership. Anything the person owns needs a new owner before their account closes: shared files, recurring calendar events, scheduled reports, and any vendor relationship where they are the named contact.
Two ownership handovers need the leaver's cooperation, so do them early rather than on the last day. In Slack, nobody can deactivate the Workspace Primary Owner. That person has to transfer ownership to someone else first. And in Google Workspace, the calendars someone owns are safest moved before their account goes. Both are notice-period conversations.
Shopify gives you two ways to close someone's access, and they are not the same. Both live under Settings > Users.
| Action | What it does | Can you undo it? |
|---|---|---|
| Suspend access | The user can no longer log in to your store | Yes. Click Reactivate at any time |
| Remove | The user is removed permanently and is no longer available in your admin | No. Shopify states it cannot be undone |
Suspend on the last day. Remove later, once you are sure nothing depends on that account. There is no advantage to removing someone on day one, and one real risk: you cannot get the account back if you discover a problem next week.
Four more Shopify checks, in this order:
If two people have been sharing one Shopify login, give the person staying their own user before you touch the shared one. Shopify says to create a separate user for the active person first. Otherwise suspending the leaver locks out the colleague too.
The exact permission names behind each role, so you know what a departing person could actually do before you close their account.
Try it on one of your own procedures.
Record a process once, AI writes the structured SOP. 3 free SOPs, no credit card.
Most small stores run on Google Workspace, and deletion there is the step with the sharpest edge. Google's documentation is plain: data owned solely by the user that is not transferred before the account is deleted is permanently deleted.
That covers their Gmail, the Drive files they own and their primary calendar. Drive files and the primary calendar are kept for 20 days, but you can only reach them by restoring the whole user inside that window.
Some things do survive. Files in shared drives belong to the organisation, not the person, so they stay put. So do groups the person created. That is the practical argument for keeping team files in a shared drive from the start: nobody leaving can take them anywhere.
Calendars have been changing. Google's documentation describes new rules under which a user's calendars, including group calendars, are deleted along with the account, and recommends transferring calendars before deleting anyone. Check how your account behaves before relying on the old rules, and move recurring team meetings onto a shared calendar either way.
So on the last day, suspend rather than delete. Google itself points to suspending a user as the way to block access while keeping their data. Its own list of clean-up steps after someone leaves includes wiping their mobile devices, resetting their sign-in cookies and revoking their security keys. If cost is the concern, Google offers an Archived User licence for former staff whose data you want to keep.
One safety net worth knowing about. If Google cannot finish transferring someone's data, it stops the deletion entirely. The account stays and the data is untouched until the problem is fixed.
Slack is simpler. Deactivating a member removes them from every channel and signs them out of the workspace on all their devices. Their messages and files are not deleted, and they are not notified. It can be reversed.
This is where small stores leak. Every app has its own users page, and nothing links them together. Closing the Shopify account closes nothing else.
| System | What to check |
|---|---|
| Helpdesk | Their agent seat, plus any macros or rules they own that others rely on |
| Email and SMS platform | Their user, and whether they could send to your full list |
| 3PL or warehouse portal | Often granted by the 3PL, not by you, so it never shows in your own lists |
| Returns and reviews apps | Separate logins, usually added ad hoc during a busy month |
| Ad accounts | Meta, Google and TikTok business access, which can outlive everything else |
| Payment and banking | Any card, payout or bank login they could use |
| Password manager | Remove their access, then rotate every shared password they could see |
That last row is the one that gets skipped. Removing someone's access to the password manager does not make them forget the passwords they already saw. Any shared login they used needs a new password, including the ones stored in the manager.
Keep a short record as you go: the date, the system, and who did it. It takes a minute per line, and it is the only way to answer the question later of whether someone's access was actually closed.
Contractors are the people most likely to still have access six months after they finished. There is no resignation letter to trigger anything. The engagement just ends. And their access was usually granted in a hurry, by whoever needed them productive that week, across five or six systems at once.
Two habits fix most of it. Write down every login you grant a contractor on the day you grant it, because the list you did not write is the list you cannot reverse. And after every peak season, open the users page in Shopify, the helpdesk and Slack, and remove everyone who no longer works for you.
An offboarding checklist points at more systems than almost any other document you own, so it rots fast. Every tool you add is a new line it is missing. Every vendor that redesigns a settings page makes a step point at a screen that has moved.
The fix is a trigger, not a calendar. When a tool joins the stack, the checklist gains a line the same day. When someone leaves and the checklist missed a login, that gap becomes a new line before the next person leaves.
Why a checklist written last spring quietly stops matching the tools you actually use, and how to catch it.
Pick the three processes the departing person owns that nobody else has run end to end, and record each one during a real run before the notice period ends. Then work the access list in order, suspending rather than removing. The recordings are the part you cannot redo once they have gone.
Two jobs. During the notice period: record the processes only that person knows and move anything they own to someone else. On the last day: close their access across every system, starting with the Shopify admin, email and chat, then every other app, and rotate any shared password they could see. Keep a record of each step with the date and who did it.
Suspend first. Suspending access stops the person logging in and can be reversed at any time with Reactivate. Removing a user is permanent and Shopify says it cannot be undone. Remove the account later, once you are sure nothing still depends on it.
Anything they owned alone that was not transferred first is permanently deleted, including their Gmail and their Drive files. Drive files and the primary calendar are kept for 20 days, but only reachable by restoring the whole user in that window. Files in shared drives belong to the organisation and survive. Transfer first, or suspend instead of deleting.
The same way as staff, with one extra risk: nothing triggers it, because the engagement simply ends. Check collaborator accounts in Shopify as well as staff users, since agencies usually work through a Shopify Partner collaborator account. Then check every app they were given access to, especially logins granted by your 3PL or other vendors rather than by you.
During the notice period, while they still do the work, and during a real run rather than a demonstration. A walkthrough recorded on the last day tends to skip the exceptions, which are exactly the parts nobody else knows.
3 free SOPs to start. No credit card required. See if drift detection keeps your docs honest.
Start for freeI built ReccordSOP after watching too many DTC ops teams lose months to undocumented workflows. These SOPs are battle-tested with Shopify operators running $1M to $50M brands.
Last reviewed September 25, 2026
Most onboarding advice is about welcome and culture. The part that actually costs money is access: what you grant on day one, and what you claw back on the last day.
"Needs admin access" is not a prerequisite, it is a shrug. Shopify's permissions are granular enough that a refund SOP can name exactly what the person running it requires, and vague enough at the top that most teams grant far more than the task needs.
The Slack message pinned two years ago is the real SOP. The document nobody reads is the decoy.
We use essential cookies for sign-in and a small amount of analytics to improve the product. Privacy policy.