A file arriving does not necessarily make an application ready. It might replace an earlier version, satisfy only one requirement or still need someone to check it. The useful question is not simply ?have we got a file?? but ?which record belongs in the current pack, and what may happen next??
We explored that distinction in our application document tracker. The application has a current document register, a version review and a handover. Each answers a different question instead of making one green progress indicator do all the work.
Define the pack around requirements
The register contains four requested items: company information, a supplier quotation, a business summary and contact permission. Each has a reference, version and received date. The reader can identify the current set without opening every attachment.
This is a more useful starting point than a folder of filenames. A folder tells you what is present. A requirement register also tells you what should be present and whether the supplied record is the one being used.
The list should be specific to the application. Asking every customer for every document a business has ever needed creates avoidable work and makes it harder to spot the items that actually matter.
A replacement should resolve a request without erasing its history
In the sample record, business summary version 01 was received on 27 October. Its entered review-until date had passed by the later administrative check. Version 02 arrived on 30 October and became the current reference.
We show both versions and explain their dispositions. Version 01 is retained as superseded; version 02 is included in the current pack. The reviewer can understand the replacement without mistaking the earlier file for an outstanding requirement.
Keep the replacement beside its history
This matters to the customer as well. If the replacement is already waiting for review, another ?please upload your business summary? reminder is the wrong message. The customer has acted; the next task belongs to the reviewer.
Completeness has a limited meaning
The register says four items are complete and there are no open requests. It also states the next step: adviser review. The administrative check establishes that the requested records are present; it does not verify all the underlying information or determine the application outcome.
Those limits should be understandable in ordinary language. ?Ready for adviser review? describes a useful transition. ?Approved? would imply a decision the completeness check has not made.
| Question | Where the answer belongs |
|---|---|
| What do we still need? | Requirement register |
| Which version should be used? | Current reference and version history |
| Has the supplied item been checked? | Review state and reviewer |
| Is the application ready to move on? | Handover with a named next stage |
| Has the application been accepted? | A separate authorised decision |
Received or accepted?
- 01RequestName the item and the acceptance requirement.
- 02ReceiveKeep the submitted version available for review.
- 03AssessAccept it or explain the replacement needed.
Make replacement requests specific
If a file does not satisfy the requirement, tell the supplier what needs to change. ?Invalid document? leaves them guessing. A request for a current replacement, a missing page or a legible copy gives them something they can act on.
Keep that explanation attached to the requirement rather than burying it in a general message thread. The next reviewer should be able to see why the replacement was requested and whether it addresses the same issue.
Our approval workflow guide covers the later decision. Collection should prepare a reviewable record for that process; it should not quietly perform the approval itself.
Design the staff queue alongside the customer checklist
A customer-facing checklist can look complete while the internal queue is growing. Decide who checks incoming files, how they are assigned and which received items need attention first. Reminders to the customer and reminders to the reviewer should follow different states.
This is where the workflow connects to client onboarding automation. The reminder rule should respond to the outstanding action, not merely count the days since the request was created.
A complete pack is ready for the next review
When we scope client portal development, we walk through an original submission and a replacement before settling the document screen. Production file handling also needs controls for access, validation and storage; OWASP's upload guidance is a relevant implementation reference. Those controls protect the file service, while the register explains what the people reviewing the pack should do with its contents.
Sources and calculation notes
The project observations come from our original page files, project records and anonymised screenshots. Recommendations describe how we would scope and review the workflow; they are not claims of deployed integrations or measured business outcomes. No numerical benefit is asserted.
- Our application document tracker project. The project page includes the design account, delivered scope and screenshots discussed in this article.
- OWASP file-upload guidance. Supports the distinction between safe file handling and an administrative acceptance decision.
External references checked on 31 October 2026.