A Document Upload Needs a Business Context

Uploading a file is technically simple. Understanding what that file belongs to is the real system-design problem.

In an operational platform, staff may need documents from an external person who does not have an account in the internal system. A generic upload folder would collect bytes, but it would leave important questions unanswered: Which person submitted the document? Which active case needs it? Who may review it? Has it replaced an earlier version? What action should happen next?

The upload needs business context.

Linking an external action to an internal record

One approach we implemented uses a dedicated submission link associated with the relevant lead. Staff send that link to the student, who can submit documents without entering the internal CRM. The received files are then attached to the corresponding lead detail rather than arriving in an unrelated shared inbox or folder.

The useful outcome is not merely that the document reached storage. It reached the record where operational work is already taking place.

The link is a security boundary

A submission link should be treated as a form of access, even if it does not require a conventional login. Its design should consider whether the token is difficult to guess, what the recipient can see, how long the link remains usable, whether it can be revoked, and which file types and sizes are accepted.

The external user should receive the minimum capability necessary: submit documents for the intended context, without gaining access to internal notes, unrelated records, or staff workflows.

Storage security also matters after submission. File access should follow the permissions of the associated business record rather than assuming that anyone who can find a storage URL may open it.

A lead and an application are not identical

In the system we are building, a lead may later produce applications for specific universities and countries. That creates an important modelling question: does a document describe the person generally, or does it belong to one particular application?

Attaching everything permanently to one undifferentiated folder can become ambiguous when multiple applications exist. Some documents may be reusable; others may be specific to an institution, destination, or stage.

The correct relationship should follow the business meaning of the document, not simply whichever screen first received it.

Workflow consequences should be explicit

A successful upload may need to notify a responsible agent, update a checklist, or make a review action available. Those consequences should be explicit workflow behavior. File arrival alone does not prove that the document is valid, complete, or approved.

My current lesson is that document handling is a domain feature, not a storage widget. A responsible design connects each document to a meaningful record, limits the submitter’s capability, preserves appropriate access control, and makes the next operational responsibility clear.

Related note: What a Business Record Actually Represents.