Completing the Parent Task Shouldn’t Close Its Evidence Requests

A client can finish the action that defines the document scope while the resulting statements, reports, and replacement files still have independent upload and review states.

The client task says:

Confirm which bank accounts were active in July.

The client replies with two accounts: checking and savings.

That action is complete.

Neither July statement has been uploaded.

If the application treats the completed task as proof that its related document work is also complete, the dashboard now shows a finished collection process containing zero bank statements.

The mistake is not the task status itself. The mistake is allowing one record’s result to overwrite the results of several different records.

Completion belongs to the expected result

A task and an evidence request can look similar in a list.

Both may have:

• a title
• an owner
• a due date
• a current condition
• a completion action

That visual similarity makes it tempting to handle them through one generic record type.

The expected result is different.

For the client task:

Action: Confirm which bank accounts were active in July.

Definition of done: The client identifies the active accounts.

For the evidence requests:

Requested item: July statement for the checking account.

Definition of done: Staff reviews the submitted statement and records the appropriate result.

and:

Requested item: July statement for the savings account.

Definition of done: Staff reviews that statement independently.

The client can complete the first action without supplying either file during the same step.

The completed task establishes the scope. It does not provide the evidence inside that scope.

One action can fan out into several reviewable records

After the client identifies two active bank accounts, the application—or the team using its project and document systems—now knows that two separate statements are needed.

Conceptually, the records might look like this:

{
  "client_task": {
    "action": "Confirm active bank accounts for July",
    "status": "complete",
    "task_due_date": "2026-08-03"
  },
  "evidence_requests": [
    {
      "requested_item": "July checking account statement",
      "expected_source": "Checking account ending in 1234",
      "evidence_due_date": "2026-08-05",
      "status": "waiting_on_client",
      "next_action_owner": "client"
    },
    {
      "requested_item": "July savings account statement",
      "expected_source": "Savings account ending in 5678",
      "evidence_due_date": "2026-08-05",
      "status": "pending_review",
      "next_action_owner": "staff"
    }
  ]
}

This is a conceptual model, not a claim about the application’s production schema.

The useful detail is that the parent action and the two resulting files do not share one completion result.

The checking statement still needs client action.

The savings statement has arrived, but staff has not yet recorded whether it satisfies the request.

The client task remains complete because the account list was confirmed correctly.

Reopening that task would also be misleading. The client does not need to confirm the account list again merely because one statement is still missing.

Parent completion should not cascade downward

A convenient implementation might include a rule like:

When parent task becomes complete:
    mark related records complete

That may work for checklist steps that all represent the same kind of action.

It does not work when the related records require independent evidence and review.

Each requested file can have a different outcome:

• Waiting on client
• Pending review
• Received
• Needs reupload

One statement may be accepted while another has not arrived.

A payroll summary may be pending staff review while a processor report needs a corrected date range.

A broad task such as “Complete the July submission package” does not remove those differences.

The relationship should provide context:

These evidence requests support this broader client objective.

It should not provide false state propagation:

The broader objective is marked complete, therefore every requested item is complete.

That shortcut hides exactly the item-level information the evidence list was created to preserve.

Owners and due dates can separate too

The parent and child records may also stop sharing the same owner.

A client task can begin with:

Task owner: Client controller
Task due date: August 3

After the client identifies the source accounts, the task is finished.

The resulting requested items can now move between different owners.

For a missing checking statement:

Status: Waiting on client
Next owner: Client
Evidence due date: August 5

For an uploaded savings statement:

Status: Pending review
Next owner: Staff
Internal review target: August 6

If staff finds that the savings statement covers June instead of July:

Status: Needs reupload
Next owner: Client

The same requested item moved from the client to staff and back to the client without changing the completed account-confirmation task.

This separation also keeps reminders honest.

The client can receive a reminder for the missing checking statement.

The savings statement should not appear in that reminder while it is pending staff review.

A general “the project is still open” condition does not provide enough information to decide who should receive the next message.

Connect the systems without merging their meanings

I used this boundary in the client task list vs evidence request list guide.

The guide does not claim that one application automatically creates task-to-request relationships.

It describes how the responsibilities can remain clear when a project or practice management system and a document-request workflow are used alongside each other.

The project system can own broader work such as:

• client actions
• meetings
• approvals
• engagement milestones
• internal assignments

The evidence workflow can own:

• named requested files
• expected sources and periods
• uploads
• staff review results
• replacement requests
• document-specific reminders

The systems may reference the same client and engagement.

They do not need to use the same completion language.

A project task marked Done answers whether its defined action was completed.

An evidence item marked Received answers whether staff accepted that specific requested record.

Using one status as a shortcut for the other makes both records less trustworthy.

Close the broader objective only on its own evidence

There is still a valid reason to connect the records.

A broader task such as:

Assemble the July bookkeeping input package.

may depend on several bank statements, a payroll summary, a processor settlement report, and a credit-card statement.

That task should not close merely because one file was accepted.

It may close after its own definition of done is met, which could include checking the outcomes of all required evidence requests.

The direction of the dependency matters.

The broader task may inspect the requested items before deciding whether its objective is complete.

The requested items should not inherit completion merely because someone clicked Done on the broader task.

Before allowing a parent status to affect related evidence, I would ask:

• Did the parent action actually produce this file?
• Does each file still require separate staff review?
• Can one file need replacement while the others remain accepted?
• Do the task and evidence have different owners or due dates?
• Would closing the child record hide a client or staff action that still remains?

If the answers point to independent work, the records need independent outcomes.

The client can finish deciding what is in scope.

The files created by that decision still have to arrive, be reviewed, and earn their own result.