Practical guide

Keep incoming client files separate from final releases

Last materially reviewed 2026-09-29

Quick answerUse a separate intake location and review its contents before promoting anything into a working or delivery package.
What to know

Give incoming material a holding place

Keep received files in a clearly named location for that project or request. Do not point every client at one shared mixed folder. Isolation helps preserve origin and makes it easier to identify unexpected content. It is an organizational boundary, not a guarantee that a file is safe, correctly licensed or suitable for the project.

What to know

Check what recipients can see

A collection route should match the client’s role. pCloud describes file requests as a way to receive material without giving access to existing contents. Confirm the actual mechanism rather than substituting a broadly shared collaboration folder. Review inherited access and the destination you selected, especially if an existing folder has previously been shared with other people.

What to know

Promote deliberately

Review the requested scope, filenames and appropriate file handling before copying accepted inputs into production. Preserve the original submitted material and record meaningful transformations separately. Do not open suspicious executables, disable security protections or assume a familiar sender makes every attachment harmless. Follow your organization’s security process for uncertain material rather than improvising a bypass.

What to know

A fictional boundary

Two clients both send a file called logo-final.png. Separate intake locations preserve which project each file belongs to. The designer labels the approved working copy after review and keeps the submitted original identifiable. The final release contains only the intended client’s outputs. This small boundary prevents a naming collision from becoming an accidental cross-client disclosure or an unexplained production substitution.

What to know

Put the decision into practice

Before reusing an old intake folder, inspect its existing access and contents. A new project label does not remove historical permissions. Keep accepted input, uncertain material and final releases distinguishable so a later colleague can explain why a particular file was promoted without relying on the original sender’s memory.

Continue when useful

Next: Client permissions

Give each participant the smallest useful role for the task; receiving a file is not a reason to expose your entire working directory.

Open Client permissions →

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 requests — Merchant documentation · help.pcloud.com · Merchant-controlled · checked 2026-09-29
  2. NCSC: using SaaS securely — Research study · ncsc.gov.uk · Publisher independence not verified · checked 2026-09-29