Offboarding the Only Workspace Owner of the Ops Library
Northline Pay is a 60-person fintech using Notion Enterprise. The only workspace owner is the head of operations, who resigns in three days. She owns 220 pages in a private Ops Library, including runbooks, vendor contracts, and 12 pages with API keys and bank account details pasted into code blocks. Forty of her pages are shared with the whole workspace; the rest are private. The IT lead is a member but not a workspace owner. HR has asked IT to deactivate her account at 5 p.m. on Friday. The company also has a compliance obligation to retain records for seven years and to rotate credentials quarterly. The departing owner is cooperative but has not documented which pages are safe to share. There is no content owner outside her team, and the ops team avoids Notion because nothing is findable.
1. What must happen before deactivation to avoid losing access to the Ops Library?
Read the worked answer
First, create a second workspace owner. A workspace with one owner is a single point of failure, and the IT lead cannot perform owner-only recovery actions as a member. Promote the IT lead or another senior manager before Friday.
Second, treat the private pages as content that must be transferred while the owner still has access. Workspace admins cannot browse another member's private pages simply because they are admins. The departing owner should move the 220 pages into an Ops teamspace where the team has a durable owner, or share them with a named successor and then move them. The 40 workspace-shared pages should be reviewed and moved into the teamspace as well. Exporting the workspace as a backup is sensible, but an export does not restore live permissions, comments, or database relations and is not a substitute for ownership transfer.
Third, deactivate on Friday only after the transfer is verified. Deactivation revokes access but does not automatically make private content usable by others. Do not delete the account or pages before the retention review.
2. How should the 12 pages containing credentials be handled?
Read the worked answer
Treat this as a security incident, not a content cleanup. Rotate every API key and bank credential that appeared in Notion, starting with the highest-privilege keys. Removing the text is not enough because page history, exports, and backups may retain it.
After rotation, remove the secrets from the pages and replace them with references to the approved secret manager or password manager. Check page history and the audit log, where available, to identify who viewed or edited those pages. Involve security and legal to decide whether the exposure triggers notification or audit evidence requirements.
Do not let the seven-year retention rule become a reason to keep live credentials. Retain the business record if required, but redact or replace the secret material and document the exception. The exam judgement is to prioritize credential rotation over page deletion, because deletion does not undo exposure.
3. Design a sustainable ownership model to prevent a repeat.
Read the worked answer
Require at least two workspace owners at all times, with a documented backup. Assign teamspace owners for each function, not individual page owners, so critical runbooks live in a teamspace with shared accountability. Create a template for runbooks that includes an owner property, review date, and classification. Move critical SOPs out of private pages and into the wiki or teamspace.
Use SCIM or group sync to automate membership where available, and maintain a manual guest review if not. Add an offboarding checklist: transfer teamspace ownership, move private critical pages, rotate secrets, review external shares, and deactivate only after verification. Quarterly, review workspace owners, teamspace owners, and pages shared with the entire workspace. The goal is not to ban private pages; it is to ensure that content the company depends on has an owner that survives any single departure.