A reliable upload–review–approval process shows at every stage which document is authoritative and who takes the next step. Give the starting file, the client's upload and the organisation's proposal distinct roles. Allow approval or rejection only on the clearly identified proposal.
This process is useful for floor plans, intake forms, revision rounds and proposals that do not fit a standard questionnaire. Without a fixed sequence of statuses, files such as ‘versie-nieuw-echt-definitief.pdf’ appear and email approval becomes detached from the document. A central environment helps only if it actually removes that confusion.
Give three documents distinct functions
In Yindle Portal, a review case supports three document roles: a base document from the administrator, an edited upload from the client and a proposal returned by the administrator. The status moves from awaiting the client's upload to awaiting a proposal, then awaiting the client's decision. Approved and rejected are separate final outcomes.
This model prevents an arbitrary attachment from being treated as the document requiring a decision. Show more than filenames in the interface: use labels such as ‘Starting document’, ‘Your submitted version’ and ‘Proposal for review’. Include the date and, where relevant, a version number.
Define the decision before building the button
‘Approve’ can have different legal or operational consequences. Agree with the process owner what the button does, who may decide, whether an explanation is required and what can still change after approval. This article is not legal advice; have the formal meaning and retention periods assessed appropriately.
Make rejection as clear as approval. Ask for a specific explanation and show what happens next. A red button without a clear next step leaves the client uncertain and leads to a phone call anyway.
Worked example: fictional interior design studio
In a fictional project, interior design studio Lijnwerk shares a blank layout drawing with client Amira. Amira downloads the file, marks her preferred wall cabinet and uploads her version. The team incorporates the mark-up into a new proposal with dimensions. In the portal, Amira sees one card labelled ‘Proposal v2 — ready for review’, rather than two apparently equivalent attachments.
Amira rejects the proposal, explaining that the cabinet needs to be ten centimetres narrower. The record returns to ‘prepare proposal’. The team uploads v3; only that version gets an approval button. After approval, the decision date remains visible. Formal or contractual validity also requires appropriate process and legal agreements.
Use the version and status check
Check every transition against this matrix before launch:
| Stage | Authoritative file | Action owner | Prevented error |
|---|---|---|---|
| Start | Base document | Client | Upload without a base document |
| After upload | Client version as input | Administrator | Client approves their own upload |
| After proposal | Proposal | Client | Decision on an old version |
| After rejection | Rejected proposal retained as history | Administrator | Silent overwriting |
| After approval | Approved proposal | Depends on the process | Unintentional reopening |
Test recovery too. The Portal code has explicit logic for restarting with a new base document. Your process must explain what then happens to the earlier upload, comments and decision.
Keep context alongside the file
A document alone does not explain why it was created. Keep the category, record, client comment, decision status and timestamp together. Give staff access to precisely that context from the administration view. For general document architecture, the guide building a customer portal provides a broader decision framework.
Also agree file formats and maximum sizes. A client who uploads an illegible photo has technically supplied something but has not usefully completed the task. Show what is accepted before submission and provide a download or preview after upload so the client can check the file themselves.
Do not report only how many cases are approved. Also track how many proposals are rejected, the average number of rounds required and recurring reasons for rejection. Many revision rounds may indicate an unclear base document, inadequate instructions or a premature request for approval. Use these signals to improve the process, not to judge clients.
Include a handover test: can an authorised colleague take over the record and identify the current version and comment without a verbal explanation?
Visit Yindle Portal to see how personal records and actions come together. To test your document workflow before development, discuss a real but anonymised review cycle with Yindle.