Administering the system

For whoever runs this installation: adding and removing people, organizing teams and boards, and the settings that decide who gets in.

Admin consoleadmin.html

For whoever runs the system. You reach it from your account menu, top right, and the entry only appears if your account is an application administrator — every action is checked again by the database, so there is nothing to gain by making the entry appear.

Getting around: the section list

The console wears the same bar as Tasks, Notes, Team and OKRs, so search, Refresh, Messages, the theme buttons and your account — the button showing your initials — are all where they are everywhere else. Three of that bar’s controls are missing here on purpose: Create, Today and Focus. None of the three is an administrative action, and the one thing this console does create — a team — has its button in the section that owns it. Its own areas are the list down the left: Overview, Organizations, Teams, Boards, People, System and Security, Email configuration, Human verification, Storage Explorer, User traffic and audit trail, and Audit.

There is no registration section, and that is not an omission. Anybody may create an account on the sign-in page; what proves the account is real is the six-digit code emailed to the address it was created with, which nobody administers. Nothing here issues, revokes or reads a code, so there is no control for it to be missing. Creating an account describes what a new person actually does.

Under the words Admin Console there is always one faint sentence saying what the area you are in governs, and that it applies to the whole application. That matters more than it sounds: the same words — teams, boards, people, email — also name settings that belong to one team, a few clicks away on the team board. This console is the application-wide one.

The section you were last in is remembered on this computer, so a reload puts you back. Signing in fresh starts you on Overview.

On a narrow window the list becomes a row of the same buttons above the content, which you can scroll sideways. Nothing is hidden.

The console in the same bar every other page wears: the brand, the navigation, search, Refresh, Messages, the theme buttons and your initials. Its nine sections are the list down the left. Create, Today and Focus are deliberately absent — none of the three is an administrative action.

More than one administrator at a time

The console does not re-read itself in the background. Nothing on screen changes until you ask it to, which is why there is a Refresh button in the bar — press it after somebody else has been working, or whenever you are about to act on a list you have had open a while.

This is deliberate. The console’s lists carry ticks, and a repaint clears them: losing a selection part way through choosing a dozen accounts would be worse than a list that is a minute old. So the trade is the other way round here than in the rest of the product — you are told what to press rather than having the page decide for you.

What this means in practice: if two of you are in here at once, refresh before you act. An account somebody else has just deactivated will still show as active on your screen until you do.

Overview: the application at a glance

Where the console opens. It answers three questions and changes nothing — every figure on it is a door to the area that owns the control.

• The figures. Active organizations, then active teams, boards and people, how many System Admins there are, the total storage footprint, and how many files are waiting to be removed. Press any of them to go to the area it came from. An organization counts as active when it owns at least one active team — an organization has no on/off switch of its own, so this figure is read from the teams inside it, and deactivating the last one is what takes it out of the count. Where that figure cannot be read yet it shows an em dash rather than a nought, so a console that has not finished loading never claims there are none.
• Recent activity. Teams, boards and accounts as they were created, plus System Admin role changes and retention runs.
• Configuration at a glance. The application-wide switches as they actually stand, read back from the database: whether application email is on, the password-strength level, the current state of human verification, the largest attachment anybody may upload, whether attachments are scanned for malware (they are not — the row says so outright, and there is no switch), and how many scopes have automatic retention switched on.
• Human verification, immediately below the password rule. It says whether the check is off, on and which of the three flows are being challenged, or on and unable to work — switched on with no site key stored, or with a value that cannot be a site key, either of which means the check never appears and nothing is being verified. Those last two are the only rows on the section that are marked, because they are the only ones asking you to do something. A dash means the settings could not be read, which is not the same as off — nothing on this section will tell you a stranger is being challenged when it does not know. Whether a secret is stored, and whether Cloudflare accepts it, is reported in the Human verification section itself; the Overview does not ask either question. And as everywhere else: passing the check grants no permission and signs nobody in, and an ordinary sign-in is never challenged.

A figure showing — has not arrived yet, and is not a nought. Four of the readings are a separate question to the database and land a moment after the rest. A zero that meant “we have not looked” would be impossible to tell from one that meant “there are none”, and on the line that counts files awaiting removal that is the difference between nothing to do and a job nobody did.

What you will not find here, and why. There is no security score, no “percentage of your quota” storage dial, and no per-team health grade. None of the three is something this system measures: there is no security measurement in the product, the database does not know what storage plan the project is on, and a letter grade for a team would be a judgment dressed as a fact. A number you would act on has to be a number something counted.

Organizations

Read-only, and deliberately so. This section is a System Admin's view of what exists — every Organization in the product, with its team count, its people count and how many Organization Owners it has — the same way Teams and Boards already let you see the shape of everything else. There is nothing to click or change here: it is not a second place to administer an Organization, and opening it does not make a System Admin an Organization Owner or grant them anything the role matrix does not already give them. An Organization is configured — its name, address, mark, Owners, billing — from Organization settings, by an Organization Owner or a God Mode holder, never from here.

If the list is empty, or the whole section says the Organization layer has not been deployed to this database yet, that is an honest answer, not a fault: it means no Organization rows exist yet on this database, rather than that something failed to load.

People

The section is called People, because that is what is in it. It was called Users, and a team’s line read “4 members”; both were the database’s words for a human being. One word across the product now.

The People section, with the section list down the left. Counts only — the console never shows anyone’s content.

Every registered account, with how many tasks, teams and boards each has.

• Inactivate — the account cannot sign in and reaches no data. Everything is kept and returns if you reactivate them. Use this for someone on leave or between roles.
• Delete — removes the account and everything it owns: tasks, notes, tags, comments, memberships, uploaded files, and any board it created that nobody else is on. Permanent.

God Mode — visible only if you already have it

God Mode is a separate, product-wide flag, not a team role and not System Admin. A God Mode user can see every Organization, every team and every board in the product. It is configured only from this People section — never from Organization settings, Team settings or anyone's own profile — and only an existing God Mode user can grant or remove it. If you do not already hold God Mode, the column and the control described below are not shown to you at all; that is not a bug, it is the same person who is asking not being told the door exists.

A person's row carries a God Mode badge when they have it. Opening their Profile shows the full control: a button that grants or revokes it, a plain sentence naming what you are about to do, and a confirmation before it happens. You cannot change your own God Mode status from here, and the product refuses to let the last remaining God Mode user be removed — there must always be at least one path back in. A God Mode reader sees (God Mode) appended to the browser tab title on every STRIDE page, so it is never a silent, invisible privilege.

The invisibility runs the other way too: a God Mode holder does not appear inside an Organization they are not otherwise a member of. They are never listed in that Organization's own People, counted in its user totals, or shown on any of its rosters — an Organization Owner looking at their own membership list has no way to tell whether a God Mode account exists. God Mode also holds no membership to leave or transfer, so it never shows a Leave-Organization control anywhere, and every action it takes stays out of that Organization's own view; this Admin Console is the only place any of it is ever visible, to another administrator.

Narrowing the People list to one team

Three controls sit above the list and they all narrow it together rather than replacing one another. The Team dropdown starts on All teams; Is System Admin keeps only the accounts that can open this console; and Search people… matches a name or an email address. Clear filters puts all of them back, and only appears while something is actually narrowing the list.

Somebody in two teams appears under either, once. Somebody in no team appears only under All teams — which is the quickest way to find an account nobody has placed yet. All three compose with the active/inactive filter as well, so “the inactive system admins on one team” is a question you can ask.

Grouping the list by team

The People list is grouped by team, one heading per team, with anyone on no team gathered at the end — usually the quickest way to spot an account nobody has placed yet. A team with no active people gets no heading at all.

Click a heading to open or shut that group, or use the single fold button beside Group by team to work the lot. It always says what the next press will do: while every group is open it is lit blue and reads Collapse all teams; once anything is shut it goes plain and reads Expand all teams. Headings work from the keyboard too: tab to one and press Enter or Space.

Your arrangement is remembered — which groups are shut, and whether you group at all — and it comes back next time you open the console, on this browser. Untick Group by team for one flat list.

Account retention: notifying, then deleting, idle accounts

Inactivate and Delete, above, are things you do to someone. Account retention is different: it is a schedule the product follows on its own, for an account nobody has signed into in a long time. It ships off — nothing is notified or deleted anywhere until an administrator turns it on — and it lives here, in People, because it is the same offboarding this section already does by hand.

Three thresholds, set here, in Account retention settings:

The panel reads these back as a plain-English sentence — "an account idle for … days is warned, warned again at … days, and may be deleted … days after that" — so you are checking the schedule you actually set rather than three numbers in isolation.

Two more controls travel with the feature, both in the People list itself:

• Dormant accounts, a filter beside Team and Is System Admin above, showing only accounts past their first notice.
• Exempt from account retention, a control on an individual person's row. Use it for a shared or service account, or anyone who should never be swept up by this regardless of how long they have been away — it clears any scheduled deletion for them immediately and keeps them out of the idle count from then on.

What is deleted follows the same "everything it owns" rule as a manual delete above, with one difference: shared work is handed to someone else first, not deleted with the account. A task assigned to somebody else stays with them; a board or a shared note goes to whoever on it has been there longest in the most senior role; an OKR hands to another listed contributor. Only work nobody else has any claim to is removed.

A task they were only assigned to, never owned, is handled separately again. Whoever owns it, that task is kept and unassigned rather than left pointing at an account that no longer exists, and gets a comment from System saying the person it was assigned to no longer has an account and that it needs reassigning. The comment does not name them — a board's readers are not always people who knew who that was. This is the deletion path only: inactivating someone touches no assignment, so a deactivated person's tasks stay theirs and reactivating them restores their workload exactly as it stood.

Deleted accounts is the record of every account this feature has removed, searchable by name or email, with what was transferred and to whom, and exportable to a spreadsheet. It is permanent and cannot be undone from here — there is no restore. It ages out on its own after a configurable number of months, the same way the rest of this section explains an old purge run eventually does; until then, every deletion this feature has ever made is on that list.

Teams and Boards

Every board, grouped by the Organization its team belongs to, with each Organization’s teams nested underneath — Organization, then Team, then Board.

Two sections. Teams lists real teams with their people, admins, boards and groups. Boards lists every board with the team that owns it. A team can only be deleted once it is empty. If it still holds boards, people, groups or OKRs, the console shows you what and how many, and offers Inactivate instead — which closes the team to its members, keeps everything, and can be undone.

Deleting a board deletes the team tasks on it. Those tasks go for good, and their comments, watchers, reminders and links to OKRs go with them — the OKRs themselves are untouched. Two kinds of task survive: anything an individual keeps on their own list rather than the board, and a team task that also sits on another board, which is simply taken off this one. Before it destroys anything the console shows you the counts, board by board, and asks you to type a short phrase to confirm. If no task would be destroyed it does not ask. This cannot be undone, so inactivate the board instead if you only want it out of the way.

Both sections group under the Organization each team belongs to. On Teams, Group by organization puts a heading above each Organization’s teams. On Boards it goes one level further — Organization, then Team, then Board — so Group by organization there nests each Organization’s teams the way Team grouping always has, with an Organization heading added above them. Click any heading, at either level, to open or shut it, or use the single fold button in the row above for the lot — on Boards one press acts on both levels at once, so the Organizations and the teams nested inside them open and shut together; a team or a board that belongs to no Organization still appears, gathered under its own No organization heading rather than disappearing.

Boards has the same controls as People. A Team dropdown narrows the list to one team’s boards, and the fold button works the lot at both grouping levels together. Boards belonging to no team, or whose team belongs to no Organization, gather at the end. Which way you arrange it is remembered on this browser; the filter is not, so the list always opens showing everything.

The same two rules apply here as on People: changing the filter clears your selection, and Select all means the rows currently shown — acting on boards that scrolled out of view is the mistake worth preventing. The count beside the section name keeps showing the full total, so a filter never looks like boards disappearing. Grouping is different: it rearranges the same rows rather than removing any, so turning it on or off keeps your selection exactly as it does on People.

OKR Cleanup

OKR Cleanup sits between Boards and People, and it is the one place an administrator can clear out objectives that should never have been kept — a duplicate imported twice, a quarter’s worth of drafts nobody adopted, a team’s whole set after a reorganisation.

Objectives are grouped by team. The fold button opens or shuts every group at once; each objective shows what is underneath it before you decide anything, because the count of key results and check‑ins is usually what tells you whether a row is a duplicate or the real one.

It works at the objective level, never the key result. Deleting an objective takes its key results, their check‑ins, every comment and every task link with it — that is the point, and it is why there is no way to delete a single measure from here. If a key result is wrong, edit it on the OKRs page; this section is for removing the whole thing.

Deleting a team’s objectives asks you to type the team’s name. The confirmation names the team and the exact number of objectives, and the count is checked again on the server before anything is removed — so a screen that has gone stale while you were reading it cannot delete more than it showed you. None of it can be undone.

Email configuration

Its own section, holding everything that decides whether a message leaves the building: the system switch, which teams may send, and a bench for trying one first.

Email configuration. The bench sends only to your own address, and Trace answers “would this send?” without sending anything.

Application email

Under Email configuration, Application email switches notification email on or off for the whole system. Off means no mentions, assignments, shares or ownership emails from any team — the Message Center carries on exactly as it is.

Signing in, password resets and other account email are not affected by this switch. They keep working whatever it is set to. That separation is deliberate and it is the reason the switch is safe to use: turning notifications off must never lock anybody out of their own account — including you.

That stayed true through a change you may hear about. On 6 September 2026 the password reset code moved onto the same mail path as notifications. It is deliberately exempt from this switch anyway, so nothing about the sentence above changed — only the wire underneath it.

Beside it: whether the mail provider is configured, how many messages were sent, failed and suppressed today, and when the last one went. Suppressed is not a fault — it means the notification was delivered in the app and deliberately not emailed, because a switch was off, it was somebody's own action, or the recipient had no address.

Send test email sends one message to your own signed-in address and nowhere else. Detailed delivery history lives in the provider's own console.

Teams

Which teams may send, and which events they send. A team ships off and stays off until somebody turns it on — here, or by a team admin in that team's own Team settings → Email. Both write the same setting, so the two views always agree.

The Application email system switch outranks every row: while it is off, nothing sends whatever these say, and the list tells you so. Events opens the same seven choices the team sees. Inactive teams are listed rather than hidden — a team that is closed but still switched on is exactly the thing worth finding.

While application email is off system-wide, no team can be switched on — here or in the team's own settings. The switch is grayed out in both places and the database refuses it either way, so a team can never read "on" while it is sending nothing. A team that was already on keeps its settings, and can still be switched off: turning email off is never the direction that is blocked.

Email bench

Directly under the switch: a place to try an email before turning it on for anybody. Nothing on the bench changes a setting, and the only address it can send to is the one on your own account — there is no recipient field, deliberately.

Preview shows the real template for whichever event you pick, with sample content instead of anybody's actual task or comment, and a banner a genuine notification does not carry. Send to me delivers exactly what the preview shows to your own address. It works even while the master switch above is off — that is the point of a bench — and it is limited to one per event per minute.

Trace answers the more useful question: would this actually send? Pick an event, a team and a person, and it walks the same checks the real sender walks, against the switches exactly as they stand right now, then reports which one would stop it — the system switch, the team's switch, that event being off for the team, the person not being on the team, or their profile routing that team nowhere. It sends nothing, records nothing and never shows anybody's address; where a message would land is reported as the sign-in address or the alternate address.

Two checks cannot be answered without a real event and say so rather than pretending: whether the recipient caused it themselves, and whether that exact notification has already been sent.

Email health

The switch tells you email is on and the bench tells you a message would go. This block tells you what actually happened. One control at the top of it — Window — sets how far back everything below reads: the last 24 hours, 7 days or 30 days. The summary and the list always describe the same period, so the two can never be reconciled against each other and disagree.

Five figures: delivered, failed, suppressed, the failure rate, and when the last message actually went out. Above them is one sentence saying whether email is healthy right now.

Suppressed is not failed, and the difference is the whole point of this block. A suppression is the system deciding not to send — a team has email switched off, you caused the event yourself, the recipient is not on the team and may not read the thing, nobody has routed that team to an address. Every one of those is a rule working. A failure is the system trying and not getting there, and it is the only figure you have to do anything about. So the failure rate is counted against attempts, not against every row: suppressions are not in the denominator, because nobody ever tried to send them.

Underneath, the reasons are broken out in two groups for exactly that reason. Failures come first, however small the number, and are the ones to act on. Suppressions follow, labeled as rules being obeyed rather than faults. Each line gives the count, the sender's own word for it — the same string Trace reports and the same one written into the record — and what that word means. A reason the console has never seen before is shown as itself rather than being hidden.

Deliveries: what, where and how

One line per delivery attempt: who it was for, the event, the address it was actually sent to, the team, the status, the reason it stopped if it did, when, and the provider's own message id where there is one — that last is the string to search for in Resend, which is where the delivery detail itself lives.

The name and the address are two separate facts on purpose. Somebody can route a team to an address that is not their usual one, so "why did Ana not get it" is only answerable if you can see where it went rather than only who it was for.

Filter by status and by event, and page through with Show 60 more. Three different kinds of empty list are worded differently and mean different things: nothing sent in this window, nothing matching the filter you set, and — if this database has not had the email-audit update applied — nothing readable at all. The last of those is never shown as an empty list, because "nothing failed" and "I cannot see whether anything failed" are opposite facts.

Retrying a failed delivery. A failure gets a tick box; Select all and Deselect all work on the failures currently on screen, and the button says how many it will attempt before you press it. It asks you to confirm, listing the addresses, because these are real emails to real people — and the sender re-runs every check it ran the first time, so anything a switch now stops is suppressed rather than sent.

How it failed, over time. The list shows each delivery's latest state, because that is what the record holds — one line per delivery, updated in place. A message that failed, was retried and failed again for a different reason therefore looks like a single failure with whatever reason came last. Any row that has been retried carries a small ▶ beside it: open it and you get every earlier attempt, oldest first, each with its own status, its own reason and its own provider id, ending with the row as it stands now. That is the honest answer to how something failed, and it is the only place it exists.

Nothing is read until you open a row, and rows that have never been retried carry no ▶ at all — there would be nothing behind it. If this database has not had the email-audit update applied the panel says so rather than showing an empty history, for the same reason the list does.

Retry queues; Send queued delivers. They are two acts and two controls on purpose. Retry marks the deliveries you selected and nothing leaves the building — the row shows queued and you can still take it back with Cancel retry. Send queued, underneath the list, is what actually sends: it tells you how many it will attempt, asks you to confirm, and then reaches real inboxes. It takes at most 25 at a time, so a long queue needs more than one press and the button says so.

The sender re-runs every check against the settings as they stand now, so a message a switch has since stopped is suppressed rather than sent. You cannot overrule a policy from here, only ask it again. Every attempt is reported back: delivered, already delivered, suppressed on the way out, or refused, with the reason for each.

Failures nobody can confirm. A failure with a clean refusal from the provider is proof the message did not go. A failure with no answer at all — a dropped connection, or a 5xx — is not: the provider may have accepted the message and only the reply was lost. Sending those again can deliver a second copy to a real colleague, and there is no way to check first. So they are held back by default. The tick box beside Send queued includes them, asks you a second question that spells the risk out, and switches itself off again as soon as the run is over — it is never left armed for the next person.

“Unconfirmed” — sent, but the receipt was lost. Very occasionally a message goes to the provider and the result never gets written back: the recording step fails, or somebody presses Cancel retry while the send is already on its way. The record still says failed, because nothing ever proved otherwise — but the message most likely arrived. Those rows carry an unconfirmed badge and the failed beside it is grayed, and the row says in words that the result was never written down.

Treat an unconfirmed row as delivered unless you know otherwise. Sending it again can put a second copy in the same inbox, and there is no way to check first. The system will not send one on its own: it is deliberately classed with the failures nobody can confirm, so only a run where you tick that box and answer the second question will attempt it again. If a run produces one, the message under the list tells you so straight away.

Only a genuine failure can be selected, and the tick box simply is not drawn on anything else. A delivered message has nothing to retry. A suppressed one must never be re-sent: doing so would deliver somebody the contents of something the system has already decided they may not read. Password resets, sign-up PINs and address-verification codes are also not retryable — each carries a one-time code with its own expiry, so re-sending the message that failed would deliver a code that no longer works. Use that account's own Forgot password or Resend code instead, which issues a fresh one.

Nor are the kinds the sender cannot rebuild from the record: a task reminder is anchored to a moment and arriving five hours late is a different message, so the next occurrence is its retry; a test or bench send has its own button a few inches up the page; and an invitation belongs to its own flow. Offering these would not merely fail — each delivery gets five retry attempts in total, and a refusal that can never change would spend one of them. Hover any row that has no tick box and it tells you which of these applies.

System and Security

System and Security: the password levels, the attachment size limit, who holds the system role and every grant or revoke of it.

Password strength — Medium, High or Extra-High, each listing exactly what it requires. Whichever you pick, set the matching minimum in the Supabase dashboard as well: the app can state the rule, but only the service can enforce it for every route in.

Attachment rules

The size limit is set here, in megabytes, between 1 and 50. It is the bucket's own limit, not a message the page shows — so it holds however the upload is made, and a file of exactly the limit is accepted. Two things are worth knowing before you lower it. Files already attached are never affected: the limit is checked when something is uploaded, so existing attachments stay exactly where they are and keep downloading whatever you set. And the number people see under the dropzone comes from this setting, so it changes for them as soon as they load a page — you do not have to tell anyone a figure, and the manual deliberately does not quote one.

If you type a number outside the range, nothing is saved and the field says so with the limit still in force. 50 MB is the ceiling the storage service itself imposes; asking for more would show a number uploads would then fail at.

The other protection on an attachment is the list of accepted file types, and it works the way round that matters: it is a list of what is allowed, not a list of what is banned. A type that is not on the list is refused, and the refusal tells the person what to do about it — put the file in a .zip and attach that, which always works because zip is itself on the list. The list is fixed rather than configurable.

Why that way round. It used to be a list of dangerous types to block, and it was a well-chosen one — but a list of banned types is a list of the ones somebody thought of. It named .hta and .vbs; it did not name .jnlp, .cpl, .msc, .pif, .chm, .url, .xll or .wsf, every one of which some platform opens or runs, and it could not name the next one because nobody has invented it yet. Accepting only what is known inverts who has to be exhaustive. The cost of getting it wrong is now somebody being told to zip a file, rather than this application hosting something that runs when it is opened.

What is on it: documents, spreadsheets, presentations and their Apple and OpenDocument equivalents; images; the audio and video a screen or meeting recording produces; archives; mail, calendar and contact files; and the project, CAD and design formats this business actually sends. What is deliberately off it: anything a browser would render as a page from a signed link (.html, .svg, .xml), anything a runtime executes, and any installer or disk image. A file with no extension at all is refused too, because there is no way to tell what it is. A few of the obviously dangerous types are still named individually — not to gate them, but so an .exe can be refused with the reason rather than the general sentence.

The list in the browser is a convenience, not the control. It exists so somebody finds out before a 40 MB upload rather than after. The rule that actually holds is on the storage bucket itself, in the database — because anything the browser does, somebody bypassing the browser can skip. Judge the protection by the bucket, never by what the page says.

There is no malware scanning: a scanner needs a service to call and an upload path that passes through it, and this application uploads straight from the browser to storage. If that becomes worth building, it is its own piece of work rather than a setting.

Orphaned data moved to the Storage Explorer, where the rest of the space accounting lives — it is rows and files taking up room, which is what that section is for. Scan looks for rows and files belonging to accounts that no longer exist. Scanning changes nothing; Clean up removes what it found.

System administrators

Two roles share the word "admin" and they are not the same thing.

• Team admin — authority inside one team or one board: its people, its groups, its swimlanes and topics. Almost nothing outside it — with one exception worth knowing: anybody who administers a team reads the whole Organization's roster, not only their own team's part of it. Reading it is not the same as changing it, and assigning people across the Organization stays with an Organization Owner.
• System admin — authority over the whole application: this console, every account, every team's data, and the ability to permanently purge content and files.

God Mode is a third, separate thing, and being a System admin does not grant it. System admin is authority over this console and its data-management tools; God Mode is the ability to see every Organization, team and board a reader would otherwise never reach — see the People section above for how it is granted. The two are deliberately never merged: a System admin gains nothing from this layer that the role matrix does not already name.

The System and Security section lists who holds the system role and every grant or revoke that has been made, with who made it. Granting it happens on the account itself: People → Profile → Application role.

Revoking is immediate and narrow: the person loses this console straight away, and their own account, teams, boards and tasks are untouched.

Human verification

This section decides whether a stranger has to prove they are a person before the application will register an account, start a password reset, or go on accepting failed sign-ins. It uses Cloudflare Turnstile, and it applies to the whole application rather than to one team.

It is off until you switch it on, and while it is off every one of those flows behaves exactly as it always has.

Where it stands is reported on the Overview, in the Human verification row directly below Password strength: off, on and which flows are challenged, or on and unable to work. This section is where it is changed, and it is the only place that can tell you whether a secret is stored and whether Cloudflare accepts it.

The controls

• Human verification enabled — the master switch. While it is off nothing is challenged, regardless of the Which flows require verification switches. This is the one to reach for first if anything goes wrong.
• Site key — the public half of the pair from your Cloudflare dashboard. It is shown in plain text on purpose: every visitor’s browser is sent it or the check cannot draw itself, so it is not a secret and hiding it here would conceal nothing.
• New secret key — the private half. See below.
• Which flows require verification — three independent switches: Account registration, Password-reset initiation and Repeated failed logins. Each names a page somebody with no account can reach.

Signing in normally is never challenged, and there is no switch to make it so. Only repeated failures bring the check out, so somebody who types their password correctly never sees it.

The secret key is written, never shown

The secret field is write-only, and that is deliberate. You can set it or replace it; you can never read it back. The box submits and then clears, the page beside it tells you only whether a secret is present, and nothing in this console can display, echo or partially reveal the value. That is enforced by the database rather than by the screen: the only thing it will answer about the secret is yes or no.

If the secret has been lost, roll a new one in Cloudflare and save that. There is no way to recover the old one from here, and that is the point of storing it this way.

Turning it off is safe

The master switch is the whole rollback. Switching it off returns every flow to what it did before the feature existed: no check is drawn, nothing that was reachable becomes unreachable, and no account, membership or password is changed by switching it either way. Nobody is locked out by turning it off, and nobody gains access they did not have.

If Cloudflare itself is having an outage, the product already handles it. Readers are refused a few times and then allowed to continue on the emailed code instead, so an outage somewhere else does not shut people out of their own accounts. You do not need to switch anything off for that.

What is not offered, deliberately: a per-person exception. If one reader’s browser will not draw the check — usually an ad blocker or a locked down network — nothing is bypassed for them, and there is no override to grant. The fixes are on their side, and The security check in the sign-in manual lists them. If it is affecting a whole team, switch the feature off while it is sorted out.

Storage Explorer

The Storage Explorer answers three questions: where is the space, what should be allowed to age out, and what needs attention. It is only visible to a system admin.

Three views, and what each one answers

• Explorer — where is the space? Four summary cards, one filter bar, and charts you can select to narrow everything at once.
• Retention — what should age out? Try a cutoff and see what it would free, set the automatic policy, and preview or run a purge.
• Maintenance — what needs attention? Database health, queued file removals, loose ends and orphaned data, and the history of every purge.

These are three views of one section, not three pages, and switching between them keeps whatever you have selected. Refresh at the top re-reads everything; the timestamp beside it says when the figures were measured.

Explorer: where the space is

One filter bar drives every chart and every table on the view. Selecting a tile, a bar or a slice sets the same filter a dropdown would.

The four cards across the top are the summary and the way in. Total storage, Purge opportunity (how much of it could safely go), Cleanup & orphaned data (loose ends waiting), and Database health. Selecting a card takes you to the view that can act on it — it does not act.

One filter, and every chart obeys it

There is a single filter across the whole view: team, data type, age and state, plus a search box. Everything on screen — the cards, the treemap, the age chart, the type breakdown, the attachment list and the team table — is a view of that one filter. No chart keeps a filter of its own, so nothing on the page can quietly be describing a different selection from the thing next to it.

You can set the filter two ways, and they are the same filter:

• From the controls — the dropdowns and the search box.
• By selecting a visual — a treemap tile, a bar on the age chart, a slice of the type breakdown. Selecting a tile inside a team sets the team and the data type together.

Whatever is active appears as chips under the filter bar. Each chip can be removed on its own, and Clear filters removes all of them at once, exactly as that control does elsewhere in the console.

The state filter is a lens, not a promise. Purge eligible and Protected are a quick way to see roughly where removable content sits, and they are deliberately cautious: content is only counted as eligible when its whole age range is already past the cutoff, so the real figure is usually a little larger. The numbers you should act on — on the cards, in Retention Opportunity, in the simulator and in the preview — come from the purge planner itself, which is the same code that carries out the purge.

Where to look first

Storage by team and data type is the fastest answer, as a treemap (area is size), a bar chart or a table — the same numbers, three ways, whichever you read more easily.

Every consumer ranked, under the Explorer, lists teams and people together, because the question is where the space is rather than what kind of thing it is. Personal rows show a name, a count and a size — never the contents of anybody's private tasks. Each row with something removable offers Preview, which selects that scope and fills in the age for you; it does not delete anything, and you still preview and type the confirmation.

One thing to know about the personal rows: personal tasks are a single scope for every account, so pressing Preview on one person's row selects all personal tasks, not just theirs. The console says so when you press it.

Largest attachments lists the biggest files with the state of the task each one belongs to. Files on completed work are marked, because attachment bytes are the one thing that genuinely leaves storage when removed.

Looking inside one team or scope

Selecting a team opens a panel beside the page with its overview (what it holds, broken down by tasks, comments, objectives, key results, insights and attachments), its retention state, its files and its history.

Its two buttons are doors, not a second set of controls. Preview purge takes you to the one preview with that scope already selected; Edit policy takes you to the one policy form. There is deliberately no second policy editor in the panel — two forms for one policy is two answers to one question.

Every task is counted, and where it is counted is not who owns it

Every task is counted, not only the ones on a board. An individual task is reported under its owner's default team, or their first team if they have not set one. Tasks counted in the totals says how many of the total are accounted for; if those two numbers ever differ, the figure is flagged.

No Team / Personal

No Team / Personal is a real scope with a real place in every chart and every list — it is not an error, a missing team or a gap in the data. It holds the content no team is credited with: tasks belonging to people who are in no team, everybody's personal notes, and comments on those notes.

Personal notes are counted separately and are never purged. They belong to the person who wrote them, not to a team, so no policy anywhere in this console can remove one. They appear in the picture because the space is real, not because anything is going to act on it.

The same name selects the personal retention policy in the Retention view. What that policy covers, and why it arrives switched off, is Personal tasks below.

Two kinds of number, and they are not the same promise

This is the one thing to understand before acting on any figure here.

• Attachment bytes are exact, and they really leave. Deleting a file removes it from Supabase Storage and the account stops paying for it.
• Row content is an estimate, and deleting rows does not shrink the database file. Postgres marks the space reusable for future rows; the table stays the size it was. So "6 MB of row content" means six megabytes you stop carrying logically — it is not six megabytes back on your quota, and deleting 500 MB of rows does not make the database 500 MB smaller.

The console marks every figure as exact or estimated and never adds the two together into a single "you will save X". Handing those pages back to the operating system means rewriting the table, which locks it for the duration; that is never run from this console, and the maintenance view says when it would even be worth considering.

Retention: what should be allowed to age out

The Retention view works on one scope at a time — a team, or No Team / Personal — chosen at the top. That choice is shared with the Explorer's team filter and with the panel, so you can never have a policy form showing one team while the rest of the page is describing another.

Trying a cutoff before you commit to one

What would this retention policy do? Type a number of days — or use the 30, 60, 90, 180 and 365 shortcuts — and the answer updates as you change it: how many records, how much space, and how far back the content it would take goes. It deletes nothing, and there is no control in it that could.

The figures come from the same planner that carries out a purge, so the simulator can never promise something a preview would then refuse.

Retention Opportunity underneath shows what the current settings would actually free, keeping exact and estimated apart, with a Preview purge button that opens the ordinary preview.

What this applies to

Three choices, and each one says what it covers before you pick it:

• Closed content only — recommended, and the default. Only work that is finished. Open tasks, objectives and key results are protected.
• Open and closed content — includes live work somebody is relying on.
• Open content only — live work only; finished work is left alone.

Anything that includes open work warns you at the point you choose it, again in the preview, and again at the confirmation. Age never makes live work safe to delete, which is why open content is treated as the highest risk however old it is.

You can also choose the kinds of content the policy covers — tasks, objectives, key results and attachments.

Automatic retention

Every team has a retention policy from the moment it is created, with conservative defaults: closed content older than 180 days, evaluated daily. Nobody has to remember to switch it on for a new team.

The form is in plain language: Automatically clean up old completed content is the on/off switch, Keep completed content for N days is the age, Check for cleanup is daily, weekly or monthly, and Protect active work keeps open work out of it. There is one policy per scope and one form that edits it.

It runs in the database, on a schedule, not in a browser. You do not have to leave this page open, and nothing depends on anyone signing in.

Personal tasks

Personal tasks means every task that sits on no team board, whoever owns it. It has a retention policy like any team, and selecting it gives you the same age, frequency and scope controls.

Every task belongs to exactly one of the two scopes. A task on a team's board is that team's, governed by that team's policy. A task on no board is personal. There is no overlap and nothing falls between them — which was not true before August 2026, when this scope was defined by whether the owner was in a team rather than by whether the task was on a board. Under the old rule, a task you kept to yourself while being a member of a team belonged to no policy at all and could never be pruned by anything.

Three things are true of this scope whatever you configure:

• Personal notes are never purged. Not here, not anywhere.
• Only tasks, their comments and their attachments are in scope. A task on no board has no objectives or key results beneath it, so those options are not offered.
• Age is measured from the completion date for anything finished — not from when it was created. A task opened in January and finished in June is six months old in June, not eleven.

Because the content is personal, the preview says how many accounts it affects and names the owner of every task it lists, and the warning before the confirmation is the strongest one in this console — whether or not the selection includes open work.

The Lean storage advisor

The advisor measures what several retention cutoffs would actually free, across every team and the personal scope at once, and recommends one. It is arithmetic over your real data, not a guess and not a model — and the figures come from the same planner the purge uses, so it can never suggest something a purge would not do.

It never deletes anything. The buttons fill an age into the policy form for you to review, or open the ordinary preview. Both still end in the typed confirmation.

Why it does not simply recommend the shortest cutoff. The shortest always frees the most — that is not advice, it is just "delete more". The advisor takes the gentlest cutoff that still captures at least 80% of what the shortest one would, and tells you the actual share, so you can disagree with it. Every cutoff it measured is listed underneath with its own numbers.

If nothing has aged out yet, it says so and offers no button. That is a real answer.

Purging now

To remove content immediately: choose the scope at the top of the Retention view, the age, what it applies to and the kinds of content, then Preview. Always preview — it is the only route to a deletion, and nothing else on this page can remove content.

The preview states outright that nothing has been deleted. It names the scope it is talking about and tells you exactly what would go — not just the tasks and objectives, but the comments, mentions, check-ins, insights and links that go with them — with the oldest and newest dates affected and how much space it would reclaim. It also says what it skipped and why, so a smaller number than you expected has an explanation rather than being a mystery. You can expand the list and read the records themselves.

The purge deletes the plan you were shown, or nothing. The preview is identified internally, and if the data changes between previewing and pressing the button the purge refuses and asks you to preview again. It cannot delete a different set from the one you reviewed.

Changing any filter clears the preview, so what is on screen always describes the selection you are actually looking at.

Maintenance: what needs attention

Everything on this view is either a reading or a repair. Nothing here purges content.

What the space is made of

Row content per data class, beside the physical relation and index bytes those rows sit in. Expect the two columns to disagree — that is the point of showing both. Some of the largest classes are never purgeable: profiles and personal notes among them. They are shown so the picture is complete, not to invite action.

The age table splits tasks by how old they are, team boards from personal, and open from completed. Open rows are shown in a quieter style because they are protected — no policy removes them unless you deliberately choose the open scope, and they are never part of a recommendation.

Database health is one line: lean, healthy, growing or needs attention. It is not a percentage of your plan — Supabase does not tell the application what your limit is, so nothing here pretends to know your headroom. It reads what is stored, how much has aged out, and whether anything is stuck. A stuck file or a broken reference outranks size: a loose end is a correctness problem, a large but healthy footprint is not.

Maintenance state reports live and dead rows per table. It reports only — nothing on this page runs a VACUUM.

Removing queued files

Attachments live in file storage, which the database cannot delete on its own. So a purge queues the files, and this console removes them — usually immediately after the purge, and otherwise with Remove queued files on the Maintenance view. Until they are gone the run is reported as partial, which is honest rather than tidy. Anything storage did not confirm stays queued and is retried; nothing is silently marked as removed.

Loose ends

Three kinds, kept apart on purpose:

• Proven — a reference to something that no longer exists. Safe to sweep. When there are any, the Database health line says how many and carries a Remove N flagged rows… button; the Orphaned data scan just below does the same job from the other direction. Either way it is the same sweep, it asks first, and it reports two numbers afterwards — how many were removed, and how many are still flagged.
• Possible — a good guess, not a fact: an id stored as text inside a note's checklist, or a task id read out of a file path by convention. These are shown for you to judge and are never removed automatically.
• Pending — files the purge queue has not managed to remove yet. Not rubbish; unfinished work, which is retried.

Two proven kinds are deliberately left alone. A board whose team record has gone missing holds other people's work, and a missing team is a fault to look into rather than a tidy-up — so it stays on this list until somebody deals with it. A team that simply has nobody in it is not a loose end at all: it is usually a team created a minute ago, and nothing in this application deletes a team.

Purge history

Every run, manual or scheduled, with what it removed, what it skipped and what failed. It records counts and sizes only — nothing that was deleted is kept here, which would rather defeat the point.

User traffic and audit trail

Who is using the application, when, and what they did — by person, by team and by feature. It sits directly above Audit, and the two answer different questions: this section is the operational record of people using the product, and Audit is the administrative record of what an administrator changed. Neither replaces the other.

Nothing in this section changes anything. There is no button here that edits, deletes or purges. It reads, and that is all it does.

It records from the day it was switched on

This is the most important thing to know before you read any figure here. The application did not keep an activity record before this section existed, so the history starts when it was installed rather than when your account did. A date range that reaches back before that point will show nothing for the earlier part — not because nothing happened, but because nothing was written down at the time. The section says so on screen rather than drawing an empty chart and letting you assume a quiet month.

For the same reason, a figure this application cannot honestly answer is absent rather than estimated. If a card you expected is missing, that is the reason, and the section will say which question it cannot answer.

Five views

• Overview — the totals for the selected dates, activity over time, which features and teams are generating it, the most active people, and when in the week the application is actually being used.
• Users — every account ranked by activity, and a panel per person with their own timeline.
• Teams — the same comparison one level up, including work that belongs to no team.
• Activity Log — every recorded event, filtered and paged. This is the drill-down surface; the charts above are ways of getting to it.
• Security & Anomalies — access patterns worth a second look. Read the next heading before you act on anything here.

The date range governs the whole section

It defaults to the last 30 days and shows the resolved dates underneath the label, so you can check a figure against a period rather than a phrase. Changing it updates every card, chart, ranking and table, and it stays put as you move between the five views.

Clear filters keeps the date range. That is deliberate: the range is the period you are studying, not a filter you accidentally left on. Returning it to the last 30 days has its own control next to it.

Filters compose, and they are shared

Team, person, activity, feature and result all narrow the whole section at once, and every one you have applied appears as a chip you can remove individually. Clicking a segment of a chart, a team in a ranking or a person in a list applies the matching filter rather than opening a separate screen — so the charts are controls, not just pictures. A filter the recorded data cannot support is shown disabled with the reason, rather than hidden, so that a question this application has never been able to answer does not look like one that was taken away.

Signals are observations, not accusations

The Security view reports things like repeated failed sign-ins from deterministic rules that are written down, and it deliberately has no score, no grade and no risk rating. A number like that reads as a judgment the application is not in a position to make, and an administrator would act on it. Everything here is an observation for a person to interpret: benign explanations are usually the right ones, and a signal is a reason to ask, never a conclusion.

What is kept, and what is deliberately not

The record keeps what is needed to answer the questions above: who, when, which team, which feature, what kind of action, whether it succeeded, and a short reference to the thing acted on. It does not keep the contents of tasks, notes or comments — a title or a reference is enough to investigate, and copying private content into an analytics table would be a second place for it to leak from. It never keeps passwords, tokens, keys or anything else secret.

Access is restricted to System Administrators in the database itself, not merely by hiding this section. Somebody who is not an administrator cannot read this data even if they ask the database for it directly.

Exporting

Export takes either what your current filters are showing or everything in the selected date range, as CSV or JSON, with a choice of columns. It can only export what you can already see on screen — exporting is not a way around anything.

Audit: what has changed, and what is not recorded

Everything the application writes down about its own administration, newest first. Metadata only — nothing that was deleted or changed is kept here, and a role record stays readable even after the account it describes has been removed.

What appears:

• Teams, boards and accounts, as they were created.
• System Admin grants and revokes, with who made each one.
• Retention runs, with what each removed and whether it succeeded.

Audit records role changes, retention runs and the creation of teams, boards and accounts. It records nothing else — see below.

Filter by kind, search the text, and press Show more to lengthen the list. Refresh re-reads the role changes and retention runs, which belong to two other sections. Nothing here can be changed or removed.

What nothing records

This is the part to read carefully, because it is the part that could mislead you. A number of administrative changes leave no trace at all, so their absence from the list above tells you nothing either way. The section names them on screen, and at the time of writing they are:

• Deactivating or reactivating a team, board or account.
• Deleting a team, board or account.
• An administrator resetting somebody’s password.
• The application email switch, and any team’s email policy.
• The password-strength policy.
• The attachment size limit.
• Changing a retention policy. (The runs it causes are recorded.)

So this is not a compliance audit trail, and should not be relied on as one. If you need every administrative action recorded, that needs building — the list above is the specification for it. Until then, an empty Audit list means “nothing of the recorded kinds has happened”, not “nothing has happened”.

There is no export. You can select the rows on screen and copy them.

Onboarding someone

There is nothing to issue first. Creating an account is open, so the sequence starts with the team rather than with this console — and the quickest version of it is one step: add the person in Team → Team settings → People and they are emailed an invitation as you save the row.

1. Add them to a team: Team → Team settings → People. Adding one person emails them their invitation straight away. It arrives from that team's name and mark rather than from the product, so a person who has never seen this application knows who is asking, and it carries a link that opens the sign-in page with their address already filled in. There is no code in it, because there is no code.
2. They follow the link and create their account with their real first and last name. The name matters — shared tasks reach a person's own task list by matching it exactly.
3. They are emailed a six-digit code and enter it to prove the address is theirs. It lasts an hour; asking for a new one replaces it. Until they do this the account reaches nothing, and it matches no invitation you have already made — so an account stuck at this step looks to you like somebody who has not registered yet. Verifying your email address.
4. Give them a board — directly, or by putting them in a group that already has access. Team membership alone gives no board access.

You can add the address before they have ever registered; the two connect automatically once the address is proved. If somebody says the invitation never arrived, the team's Email invitations dialog sends it again — nothing is spent by re-sending.

Offboarding someone

Two options, and the difference matters. There is also a third, automatic path for someone who simply stops signing in — see Account retention in People, above.

Who can see what

Someone can hold different roles in different teams — a team admin in one and an ordinary member in another.

This table is a summary, and the product holds the exact one. Permissions by role — opened from Edit assignments, Assign people, or its own button on the Organization's People pane — lists every capability against all four roles, says which ones are conditional and on what, and is generated from the rules the database actually enforces. Use it when the answer matters; see how to read it.

What this console cannot do

• It cannot change a password. People reset their own with "Forgot password?" on the sign-in page.
• It cannot read anyone's data — the lists show counts, never contents.
• Password strength is stated here, enforced in Supabase. Setting a level in Security tells the sign-in page what to require; set the matching minimum in the Supabase dashboard too, or other routes in are unaffected.
• It cannot undo a deletion. There is no recycle bin.