Data that should be here is not
Three unrelated things produce the same empty screen. The record may belong to another workspace, in which case the emptiness is correct. It may be filtered out by the screen itself. Or it may carry no workspace stamp at all — matching no scope and no policy — so every list omits it silently while actions naming it directly still work.
What the symptom looks like#
A record you know exists is not in the list that should contain it. Nothing errors. Counts look plausible, because a count is derived from the same query that omitted the row. Somebody who was looking at the record last week cannot find it today, and there is no message anywhere explaining why.
The third case has a signature worth memorising: the record is missing from every list, and yet an action that names it directly — a link somebody saved, a bookmark, a screen opened from an older tab — still works on it. Missing from lists but reachable by name is not what a permission refusal looks like, and it is not what deletion looks like either.
The three silences#
| Cause | What is true | Direct access | Is it a fault |
|---|---|---|---|
| Another workspace owns it | The row exists elsewhere and this workspace has no claim on it | Also refused | No — this is isolation working |
| The screen filtered it | The row is here; a folder, a saved view, a search or a soft deletion excludes it | Works | No — a setting, and reversible in seconds |
| The row has no workspace stamp | It exists, belongs to nobody, matches no scope and no policy | Works | Yes — this one is a defect |
The third row is the interesting one, and it is worth being precise about why it behaves as it does. A scoped query asks for rows belonging to a given workspace. A row whose stamp is empty is not that workspace's row, so the filter omits it; it is not any other workspace's row either, so no policy admits it anywhere. It is invisible rather than missing — present in the table, absent from every scoped list, and still reachable by anything that names it without asking a scoped question.
Why the repair belongs to the schema owner#
The obvious fix — have the screen stamp the row with the current workspace — does not work, and understanding why is what stops somebody trying it twice. A write made in the course of a request is checked by the database policy on the way in. A row that matches no policy cannot be written into one by a request, so the attempt is refused, and an invisible row becomes a visible error instead of a repaired record.
The repair therefore belongs to the component that owns the schema, running at start-up as part of migration, where it can act as the schema owner rather than as a tenant's request. It runs every boot, so a row that acquires an empty stamp is repaired at the next restart rather than waiting for somebody to notice. A row with no workspace stamp is invisible, not missing sets out the reasoning and its limits.
What Connect completed, and what it did not#
Completed: the query, honestly. The list returned what the scope actually contains. Nothing was hidden from you by a permission, nothing was deleted, and no other workspace's records were consulted in the process.
Not complete: in the third case, the row never joined the scope it should have joined. Any work that depends on finding it by listing — a sync, a duplicate check, a headline count — has been operating without it, quietly, for as long as the stamp has been empty.
What you can do#
Clear the screen's own filters first: search text, folder, saved view, and anything hiding removed items.
Result That eliminates the second cause in a few seconds, and it is the likeliest of the three.
Try reaching the record directly, by an old link or from a screen that names it.
Result If a direct route works and no list shows it, you have the third case rather than the first.
Stop before re-adding or reconnecting anything.
Result Re-adding is what turns one invisible record into two real ones. Report it instead — the repair is cheap and the duplicate is not.
What an administrator can do, and when to escalate#
- Confirm whether other members see the same absence. A person-specific absence is a permission or a saved view; a shared one is not.
- Check whether the record was removed rather than hidden — a removal is a marked row, not a silence, and it shows as removed rather than as nothing.
- Escalate immediately if a record is absent from lists and reachable directly. That combination is the defect, and it is repaired at start-up rather than from a screen.
- Escalate too if a headline count and a list disagree; a number derived from a limited slice is a different fault with the same feel. See Headline numbers that stop at the page size.
Questions#
Could another workspace be seeing my missing record?
No. A row with an empty stamp belongs to nobody and matches no policy, so it is not visible to another workspace either. The failure mode is disappearance, not disclosure, which is the right direction for a failure to go in.
Can I fix it by editing the record and saving?
That is the attempt the policy refuses. A request cannot write a row into a scope it does not already match, so the save fails rather than repairing anything. The repair runs at start-up, as the schema owner.
How would anybody notice this without a report?
Often by the duplicate rather than the absence — a second record appearing for something that already existed. That is why the advice is to stop before re-adding: the duplicate is both the symptom and the damage.