How does the system know which documents a file requires?

It does not, and it should not. The adviser defines the item list for the file, either manually or from a template they built. The system's role begins after that definition: track the state of each item, compute what remains, and remind based on state.

What is the difference between a missing item and an expired one?

A missing item never arrived. An expired item arrived, was reviewed and accepted, and the validity window the adviser set for it has since passed. The distinction matters because the wording to the client is completely different, and a renewed document enters as a new version rather than a new item.

Is it acceptable to leave personal documents in a message thread?

That is a business decision rather than a technical verdict, but the operational difference is clear: a thread has no per-item state, no access log and no controlled deletion. A dedicated link with permissions and a retention policy gives all three without giving up messaging as a reminder channel.

How many reminders do you send before stopping?

That is the adviser's call, but reminders should be driven by state rather than by a uniform schedule: only for items not in an accepted state, with a named list of what remains. A reminder that repeats items already received teaches the client to ignore it.

Mortgage Adviser - Yehonatan Saadia

A mortgage adviser's client file is a list of items, each holding one state from a closed set. "Missing" is not a feeling but a computed value: the items the adviser defined, minus those sitting in an accepted state. The rest of the system is only the surface that moves an item from one state to the next safely.

This is a technical description of a document-collection workflow, not financial advice, and it does not state which documents any lender requires.

What does "missing" mean once you try to compute it?

Missing is the difference between two sets, so both have to be defined first. The first is the list of items the adviser set for this file, each with a stable id, a human-readable name, and which person or entity in the file must supply it. The second is the collection of files actually received, each attached to exactly one item.

From there, three separate numbers that must never be merged:

Still to collect - items not in an accepted state.
Waiting for review - items received and not yet checked by a person.
Needing renewal - items previously accepted whose validity window, as the adviser defined it, has passed.

A client shown one large number gives up. A client shown three numbers understands that the work is moving and that part of it is not on their side.

The state machine for a single item

State	What it means	Who moves it	What the client sees
Not requested	The item is on the list, no request sent yet	The adviser	Not shown
Requested	A request was sent, with a date and a channel	The system on send	Appears in their task list
Received	At least one file was uploaded	The client	Marked as received
Readable	The file opens, is complete, and is legible	Human or automated check	No change
Not readable	Cropped, blurred or partial	The reviewer	A repeat request with an explicit reason
Accepted	The item is closed for this file's purposes	The adviser	Marked as done
Expired	Previously accepted, and its validity window has passed	The system, by date	A renewal request, not a new request
Superseded	A newer version replaced an earlier one	Client or adviser	Only the latest version is shown

The two states usually missing from hastily built systems are "not readable" and "expired". Without them every problem looks like a file that was never sent, and the client receives the same message again and again for no comprehensible reason.

Why is a chat thread not a document store?

Because it is a stream of messages rather than a set of records. The difference is measurable:

What is needed	Chat thread	Dedicated upload link
State per item	None	An explicit field
Binding a file to an item	Whatever the reader infers	Chosen at upload time
Deduplication	Manual	By content hash
Who viewed a file and when	None	An access log
Deletion at the end of a retention period	Not realistic	Policy driven
The latest version	Whatever is furthest down the scroll	A version field

This is not an argument against messaging. A message is an excellent channel for a reminder and a link, and messaging queues at scale are covered in running a high-volume message queue. The only claim here is that the file itself should not live in the thread, but somewhere that has state, permissions and a date.

What the upload surface has to carry

A per-file link with a long random token, a defined expiry, and the ability to revoke it immediately.
Item selection before upload, so the file binds to an item instead of piling into a general bucket.
Metadata on every file: id, item, uploader, received timestamp, original filename, size, MIME type and content hash.
Type and size validation on the server, not only in the browser.
An access log recording every view and download, including by staff.
A retention and deletion policy set at file level, on the same basis described in a digital document archive and retention.
Narrow view permissions: who on the team can see a file, and what remains after it closes.

A request message carrying a link and a file reference should avoid spelling out personal identifiers in the message body. ID numbers, account numbers and income details belong inside the secured file, not in a preview line that renders on a locked screen.

What do you do with a file that arrived and cannot be read?

Return it to the queue with an explicit reason, never as a generic request. Four causes cover nearly everything, and each deserves different wording:

A cropped photo. Part of the page is missing. The request names which part.
A multi-page document uploaded partially. One page arrived out of several. The request names how many pages are outstanding.
A screenshot instead of a file. Legible to a human but missing fields. The request asks for the original file.
A password-protected file. It only opens with a code. The request explains how to send an open version safely.

Automatic field extraction can speed the review up, but only when it returns a confidence level rather than a single value. That principle is set out in reading Hebrew documents with confidence levels: a low-confidence value goes to human approval instead of being stored as though it had been read.

What breaks in practice

A list stored as free text. With no item id you cannot compute what is missing, and every file is managed from scratch.
A file uploaded to the general bucket. No item moves, and the client is certain they are finished.
Versions piling up. Three uploads against one item with no version field, and nobody knows which one was reviewed.
A uniform reminder to everyone. People who already sent theirs get the same message and stop reading the next ones.
A link with no expiry. A token still live months after the file closed.
Documents kept forever. With no deletion policy, every closed file goes on holding personal material with no operational reason.

Sources

Israel Privacy Protection Authority

Mortgage Adviser: A Document-Collection Workflow That Shows What Is Missing Without Sending Everything Over Chat

Key takeaways