A Status Column Wasn't Enough for My Document Request Tracker

I ended up separating item status from next-action ownership because an uploaded file can still leave the wrong person getting chased.

A bank statement can already be uploaded while a payroll report in the same request is still waiting on the client.

That sounds obvious until both items live under one request marked Open.

At that point, the request status is technically correct, but it is not very useful. Should the next button send a reminder? Should someone review a file? Is the client still holding things up, or is the work now sitting with the bookkeeping team?

I ran into this while working through the structure of a document request tracker. I initially thought a clean set of status labels would be enough.

It wasn't.

Status tells me what happened, not who acts next

For an individual requested item, labels like these are useful:

• Waiting on client
• Uploaded / Pending review
• Received
• Needs reupload
• Not applicable

But they answer only part of the question.

Take Uploaded / Pending review.

The client has completed an action. A file exists. But the item is not finished, because somebody on the bookkeeping team still needs to review it.

If the interface only knows that the overall request is open, a reminder system can easily make the wrong assumption: open request = client still owes something.

That is exactly the behavior I wanted to avoid.

So I started treating next action as separate information rather than trying to squeeze it into another status label.

For the tracker page, the useful fields ended up looking more like this:

Request context
- Client
- Request period
- Requested item
- Account / source
- Due date

Current work
- Current status
- Client action needed
- Request owner
- Review owner
- Next reminder date

After review
- Review outcome
- Next action
- Notes

This isn't meant to describe the application's database schema. It's the information structure I wanted the page and copyable tracker to preserve.

The difference matters because two items with the same request can have completely different owners at the same moment.

One request can contain several independent next actions

Imagine a July request with four items:

Operating bank statement
Received

Business credit card statement
Uploaded / Pending review

Payroll report
Waiting on client

Merchant report
Needs reupload

The request itself is still open.

But "open" tells me almost nothing about what to do next.

The bank statement needs no further client action. The credit card statement belongs with a staff reviewer. The payroll report still needs a client upload. The merchant report needs a specific replacement.

Treating those four items as one request-level task throws away the information the team actually needs.

That became the main reason I kept request context and item-level next actions together in the document request tracker.

I still want the client, period, due date, and request owner visible once. I don't want to duplicate all of that for every file.

But underneath that request, each item needs to carry enough information to answer a much smaller question:

Who needs to do something now?

That turned out to be more useful than adding another variation of "open."

Reminders should follow ownership

The reminder field made this design choice harder to ignore.

If an item is Waiting on client, a future reminder date makes sense.

If the client uploads the file and the item becomes Uploaded / Pending review, that same reminder should no longer behave as though the client is late. The next action has moved to staff.

And if staff reviews the upload and marks it Needs reupload, ownership moves back to the client — but now the request is for a replacement tied to that specific item.

So reminder behavior cannot safely depend on request-level completeness alone.

It needs the item-level context.

That also changes how I think about rejection. Creating a brand-new requested item after every bad upload would make the history harder to follow. Keeping Needs reupload attached to the affected item preserves why the replacement is being requested and who currently owns it.

The tracker can stay open without pretending every unresolved item is unresolved for the same reason.

The field I would keep even in a small MVP

It is tempting to simplify an MVP by removing fields such as Next action or separate request and review owners.

I would probably keep the next-action concept.

A status label is useful for describing the past:

The file was uploaded.

A next action describes the present:

Staff needs to review it.

Those are different pieces of information.

Once reminders, review, reuploads, and partial submissions exist in the same request, that distinction stops feeling like extra metadata. It becomes what prevents the interface from asking the wrong person to do the wrong thing.

For a small tracker, I don't need a giant workflow engine.

I do need to know whose turn it is.