Wrong final version
Generic names such as final-final or export-new make it difficult to prove which release the client accepted.
How to securely deliver client work
Treat the handoff as a release. Put the approved deliverables in a dedicated Vault folder, wait for the complete upload, and create a scoped share for the client. Use Relay only when both sides have scheduled a live delivery.
Keep drafts, internal working files, and unrelated clients outside the delivery scope. A professional handoff should make the final version, contents, access window, and acceptance step obvious.
A professional handoff is a release, not an open project folder.
The client should receive the approved deliverables, a manifest, and clear instructions. They should not have to browse drafts, infer which version is final, or enter the internal workspace.
Where client delivery breaks down
A technically successful upload can still be a poor delivery if the client receives the wrong revision, an incomplete folder, a stale link, or more project access than the contract requires.
Incomplete package
Linked assets, fonts, captions, documentation, licenses, or checksums may be missing even when the main file is present.
Broad workspace exposure
Sharing a working folder can reveal drafts, internal notes, unrelated deliverables, or future revisions.
No closure step
Links remain active, storage accumulates, and nobody records whether the client downloaded or accepted the release.
Compare client delivery methods
Vault is the default when the client needs a pickup window. Relay is the live alternative. Conventional methods can still fit small or automated jobs, but the access and release model should be explicit.
| Method | When it works | Limitation | How PhotonFile fits |
|---|---|---|---|
| PhotonFile Vault share | The client should download later from a controlled release | The retained package uses Vault capacity and needs lifecycle management | Shares the selected file or folder without opening the project workspace |
| PhotonFile Relay | The client is ready for a scheduled live handoff | Both sides must stay active and there is no later pickup window | Moves the final package now without making retained storage the default |
| PhotonFile Vault Sync | Ongoing project work that needs a dedicated local working folder | Choose the right Vault boundary and review sync state for the selected folder | Keeps one local folder aligned with its distinct Vault instead of relying on a broad cloud-drive project folder |
| Email attachment | A small, routine deliverable | Limits, mailbox copies, and version confusion grow quickly | Use the email for the release note and a PhotonFile link for the actual package |
| Cloud-drive project folder | The client is an ongoing collaborator inside that drive | Drafts and future changes may be exposed unless permissions are carefully separated | Use Vault Sync for the ongoing project folder, then a dedicated Vault release folder and scoped share for the handoff |
| Client portal | The organization already operates a formal portal with acceptance controls | Setup and account friction can be excessive for a single delivery | Use PhotonFile when a direct controlled file handoff is the task |
| FTP or SFTP | The client requires protocol-based or automated exchange | Credentials, client software, and server administration remain part of the workflow | Use PhotonFile for human-driven delivery and keep SFTP for integrations that depend on it |
Build a client-ready release
-
1. Freeze the approved version
Use a release name that includes the project, deliverable, version, and date where useful.
-
2. Separate internal work
Copy only approved files into a clean release directory rather than sharing the active working tree.
-
3. Add a manifest or README
List the included files, software or format requirements, checksum, license notes, and support contact.
-
4. Test the release from a clean location
Open or extract the copied package without relying on paths from the internal workstation.
-
5. Choose the access window
Use Vault for later pickup and managed sharing. Use Relay for a scheduled live handoff.
-
6. Define acceptance
Tell the client how to confirm receipt, report a problem, and distinguish a correction from a new scope request.
Vault workflow
Deliver a controlled release for later pickup
- 1. Choose a client or project Vault. Use the Vault boundary that matches the work and intended collaborators.
- 2. Create a clean release folder. Keep drafts, internal notes, source secrets, and unrelated work outside it.
- 3. Upload the final package. Include the manifest, README, checksums, and supporting files the client needs.
- 4. Wait for complete upload. Review every expected item before creating the share link.
- 5. Share the smallest useful scope. Select the final file or release folder rather than the active project root.
- 6. Send a release message. State the version, size, contents, deadline, instructions, and support path.
- 7. Record acceptance. Ask the client to confirm receipt and any checksum or opening test required by the project.
- 8. Close or retain access deliberately. Revoke the link when appropriate and keep the release according to the contract and retention policy.
Relay workflow
Use a scheduled live handoff when pickup later is not needed
- 1. Package the final release. Use one tested archive when the client needs a directory structure.
- 2. Schedule the handoff. Confirm the client is ready and has enough local storage.
- 3. Select the release in Relay. Check the filename, version, size, and checksum before starting.
- 4. Enable optional client-side encryption when appropriate. Use the supported encrypted flow when the recipient environment can open it.
- 5. Share the live link. The client can receive the Relay transfer without creating a PhotonFile account.
- 6. Keep both sides active and verify completion. Use eligible resume or Retry behavior if interrupted, then confirm the downloaded release.
Release boundary
Share the deliverable, not the studio
A scoped Vault share keeps drafts, internal discussion, and unrelated client work outside the delivery.
Client experience
No account is required for download
The client receives a direct file task rather than another workspace to learn and maintain.
Access closure
Revoke when the release window ends
End future use of the link while remembering that copies already downloaded remain with the client.
Handle updates as explicit releases
A Vault share is fixed when you create it. It is tied to the selected file or directory and the specific shared items at that time, so a later upload or revision does not change the link.
To deliver an update, create a new share link for the intended version or release folder, then tell the client what changed and which link is current.
Separate feedback from delivery
Use the delivery link for outbound files. When the client needs to return source material, corrections, or signed documents, use a dedicated Secure Inbox so the upload task does not expose the Vault.
Outbound sharing and inbound intake are different access paths.
Common questions
Frequently asked questions
Should I use Vault or Relay for client delivery?
Use Vault when the client should retrieve the release later or the share needs to remain manageable. Use Relay when both sides have scheduled a live handoff and no retained pickup window is needed.
Does the client need a PhotonFile account?
No. Clients can download from a Vault share or receive a Relay transfer without creating a PhotonFile account.
How should I send a folder of deliverables?
Upload the complete release directory to Vault, wait for every item to finish, and share the selected folder. For Relay, package the release as one tested archive first.
Can I replace a delivered file after sharing it?
No. A Vault share is fixed when it is created, including its selected file or directory and specific shared items. A later upload or revision does not change the link. Create a new link for the updated release and tell the client what changed.
Can I revoke client access later?
Yes, revoke a Vault share when access should end. A completed download may still remain on the client device, so revocation is not remote deletion.
How should the client confirm delivery?
Ask the client to confirm the release name, file count, size, and checksum when used. Record acceptance against the manifest rather than relying only on a successful link open.
Keep going
Related guides
Share files without requiring an account
Keep the client download separate from workspace membership.
Send an entire folder online
Preserve directory structure, linked assets, and project packaging.
Send sensitive documents securely
Add recipient verification, access controls, and deliberate retention.
Product and technical references: Vault sharing guide Vault overview Relay guide Secure Inbox guide Desktop and Vault Sync guide
Deliver a finished release, not a workspace.
Put the approved files in a clean Vault release folder for later pickup, or schedule a live Relay handoff when both sides are ready now.