Clanker CloudOnce you have reviewed a Workspace file, you can share it without turning it into a public App or copying an entire conversation. Open the file's sharing controls and choose the access route and revision behavior that suit the handoff.
Private file sharing requires sign-in. That gives you an account-based access path, but the audience still depends on the share you choose. A private link and a grant to one named account have different purposes.
Review the file you intend to share
Open the result from Project Files or its Session preview. Check the filename, contents, source references, and revision. Include the information the recipient needs to understand the work.
In a fictional client update, the reviewed report contains approved milestones and two open questions. An internal staffing note is outside the handoff's intended scope. Prepare a client-facing file and inspect it before sharing.
The file preview walkthrough covers opening documents, spreadsheets, and slides. If the deliverable depends on a workbook calculation or formatting in another application, complete the relevant downloaded-file check too.
Choose a link or direct access
The file viewer provides Share or Share privately controls. Choose from the available options for that file and account:
| Access route | What to consider |
|---|---|
| Private link | Anyone signed in with the link can use that link's granted access. Distribute it accordingly. |
| Direct user access | Select the intended Clanker Cloud account by its public profile handle. |
| Team access, where available | Select the team whose membership matches the audience. |
The sign-in requirement does not make a link exclusive to a particular colleague. If the intent is to grant access directly to one account, use that route and verify the handle.
These controls share the selected file. Do not infer that the recipient receives your whole Project, every Session, or an Agent's credentials. Sharing an Agent or publishing an App uses its own workflow.
Decide which revision the recipient should see
File sharing supports access pinned to a revision or following the latest revision. The distinction matters when you continue editing after the handoff.
For the fictional report, a reviewed October update might be pinned to the revision the client received. A working tracker intended to change could follow the latest revision. Read the displayed choice and check what is enabled before creating the share.
Following the latest revision means a later edit may become visible through that share. Review future changes with the shared audience in mind. Pinning a revision helps keep a handoff stable, but it also means the recipient may need a newly reviewed share when you want them to receive an update.
Add a short usage note stating the file's purpose and whether it is a fixed handoff or an evolving result. This helps the recipient interpret an update without assuming every newly saved draft is approved.
Check the recipient path and manage access
Verify the share using the intended recipient's permitted signed-in context, or arrange a check with them. Confirm that the expected file and revision open. Your owner view establishes that the file exists; the recipient path establishes that the chosen access works for that person.
Use Shared to find Shared with me and Shared by me. Outgoing shares show their audience and revision behavior, and access can be revoked. Revocation changes future access through the share; it cannot recall a copy someone has already downloaded.
Organization policy can limit sharing, so use the options actually available in your Workspace. Keep the reviewed result in its Project and use the share as a deliberate handoff to its intended audience.
Sources
Give your assistant one useful job
Keep the final file, source context, and intended recipient experience clear.