Practical guide

Handle duplicate submissions without guessing the intended version

Last materially reviewed 2026-09-29

Quick answerPreserve both submissions until their relationship is clear; filename or upload time alone does not establish which file the client intends you to use.
What to know

Identify the source of confusion

A duplicate may be a repeated upload, a corrected file with the same name or a different export of the same work. Record the request and arrival context before merging anything. The most recent timestamp can reflect transfer time rather than editorial approval. Keep the question focused on which version satisfies the current brief.

What to know

Avoid destructive shortcuts

Do not delete one copy simply because its name matches another. Keep separate temporary labels or locations while comparing the intended scope through your normal safe file workflow. If you use automated duplicate detection, understand whether it compares bytes, names or visual similarity. Those methods answer different questions and do not decide the client’s business intent.

What to know

Resolve the meaning

When the difference matters, ask the responsible client contact to identify the accepted version through the agreed project channel. Record the decision in the project, not merely in your memory. A small clarification about an actual input is different from repeatedly requesting all files again. Keep superseded material private and distinct from the eventual release package.

What to know

A fictional repeated logo

A client uploads logo.pdf twice. One includes an added mark; the other is the approved original exported later. Sorting by upload date would select the wrong artwork. The studio retains both until the client identifies the intended version, then labels the working copy accordingly. The final delivery manifest references that choice so a future collaborator does not reopen the same ambiguity.

What to know

Put the decision into practice

Record which candidate became the working version and why. Keep the decision with the project rather than only changing a filename. If later work reveals a mistaken selection, that record helps isolate the affected release instead of forcing a broad investigation of every file received during the project.

Continue when useful

Next: Input naming

Use project, purpose and version labels that people can interpret; a renamed file should not lose the context of the original submission.

Open Input naming →

Sources used for this page

These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.

  1. pCloud file transfer and organization — Merchant documentation · help.pcloud.com · Merchant-controlled · checked 2026-09-29
  2. pCloud file requests — Merchant documentation · help.pcloud.com · Merchant-controlled · checked 2026-09-29