# Share a reviewed App with the intended people. Reviewed: 2026-09-12 Canonical: https://clankercloud.ai/learn/share-apps-privately Review the App and its data, choose private sharing, and manage the share in Shared. Recipients need to sign in. Test the actual recipient path and confirm the intended access before distributing the link; use publication only when you intend to create a public link. ## What you are working toward A reviewed private App share with a checked recipient experience and a clear handoff. ## Start with - A tested App version and a defined audience - A review of all data visible through the App - A way to check the intended recipient’s signed-in experience ## Choose the access outcome first Creating or previewing an App does not publish it. Private sharing requires recipients to sign in; publishing creates a public link. Choose based on who should access the result and what it contains. A project dashboard for selected colleagues has a different audience from a public demonstration with fictional records. Use the sharing controls available in Workspace and manage private sharing in Shared. Read the displayed access choices before applying them. This guide does not assume that every App provides a custom role system, an organization-wide permission model, or access behavior beyond the options shown for the actual resource. ## Review everything the recipient can discover Inspect the App with filters cleared as well as applied. Look through details, alternate views, and any enabled export or download path. Information hidden by the initial view may still be present elsewhere in the App. A clean first screen is not a complete data review. Remove sample records that could be mistaken for real work, internal notes that are inappropriate for the audience, and unnecessary personal details. Review the actual built result after changes. Do not rely on a prompt saying “keep this private” as evidence that the App’s contents and access configuration match the intended handoff. ## Prepare a fictional client tracker for sharing In this fictional example, Cedar Studio wants to share project status with one client. The internal tracker includes approved milestones, staff planning notes, and a sample task used during testing. The correct preparation depends on each item’s purpose, not whether it appears near the top of the table. The public demonstration is a separate decision with a different dataset. Keeping that distinction explicit avoids treating private sharing as an intermediate step that inevitably becomes publication. The owner can choose to keep the reviewed client version private for its entire useful life. | Content or action | Private client version | Reason to inspect it | | --- | --- | --- | | Approved milestones | Include after checking dates and labels. | These support the client’s workflow. | | Internal staffing note | Remove from the shared result. | It is outside the recipient’s intended scope. | | Fictional testing record | Remove or clearly label in a separate demo. | It could be mistaken for a real commitment. | | Public publication | Do not enable for this handoff. | The intended audience is selected recipients. | ## Test the recipient path, not only the owner view Open the private link using a permitted recipient’s signed-in context or arrange a check with that recipient. Confirm that the expected resource opens and its main workflow works. The owner’s view may establish that the App exists, but it does not prove that another person can access or use it. Also inspect the signed-out experience without supplying credentials to the wrong context. Private access should require sign-in. If the recipient reports a problem, confirm the account they used and the sharing configuration before changing the App’s visibility. Publishing publicly to bypass an access problem changes the audience and is not an equivalent repair. ## Explain what the App does and what it does not Write a short handoff note naming the App’s purpose, the data period, the main actions, and any known limitations. State whether displayed data comes from a reviewed snapshot or a verified update process. Saving a spreadsheet or Google file into a Project does not establish automatic synchronization with that source. If edits are supported, describe the behavior you actually tested, including what happens after reload. Do not promise shared live data, durable storage, or cross-device behavior unless the build implements it and you have checked it. A concise limitation helps the recipient use the result correctly and report a useful problem. ## Review access when the work changes Return to Shared to manage private sharing as the audience or purpose changes. Inspect the available controls and verify the resulting access behavior when you make a material adjustment. Do not assume that changing access can recall information a recipient already viewed, copied, or downloaded. Before sharing an updated build, rerun the main workflow and the data review. A change intended to improve the interface may expose a previously hidden field or alter the meaning of a count. Keep the recipient-facing note aligned with the version in use, and make publication a separate intentional decision if a public audience is later required. ## Try this prompt Copy into Apps. Opening Workspace does not send it automatically. ```text Help prepare this App for private sharing. Review the current build, list the data and actions exposed through its interface, and identify sample or internal information that should be removed. Prepare a recipient checklist and a short usage note. Keep sharing private and do not publish a public link. I will review the selected audience and final result before distributing it. ``` ## Before using the result - The intended audience matches the selected sharing path. - All reachable data has been reviewed, including filtered-out records. - A permitted recipient can open and use the App. - Signed-out access follows the private-sharing sign-in requirement. - The handoff describes only tested data and edit behavior. ## Common questions ### Are Apps and files public as soon as I create them? Creating or previewing an App does not publish it. Private sharing requires recipients to sign in. Publish only when you want a public link, and review the data included in the result. Manage private sharing in Shared. [Read more in the FAQ](https://clankercloud.ai/faq#sharing) ### Can I build an App from a spreadsheet or idea? Yes. Open Apps and describe the user, inputs, and actions you need. Start with sample data, inspect the private preview, try the main actions on large and small screens, and ask for changes before sharing or publishing. [Read more in the FAQ](https://clankercloud.ai/faq#apps) ### Can I work with Google Drive, Docs, and Sheets? The experimental Google connection lets you choose accessible files in External Apps, create or edit Docs and Sheets from a Session, and save copies to a Project. Saving a copy is not automatic live sync; request a fresh copy when you need updates. [Read more in the FAQ](https://clankercloud.ai/faq#google-files) ## Sources - [Workspace guide: share and publish Apps](https://workspace.clankercloud.ai/#page=faq&tab=articles&article=apps-from-work) - [Workspace guide: copies and source updates](https://workspace.clankercloud.ai/#page=faq&tab=articles&article=google-files) ## Related - [Test the workflow behind the preview.](https://clankercloud.ai/learn/test-a-private-app) - [A spreadsheet in. A useful App out.](https://clankercloud.ai/learn/build-an-app-from-a-spreadsheet) - [Keep the result and the context needed to trust it.](https://clankercloud.ai/learn/save-and-reuse-results) [Open Workspace](https://workspace.clankercloud.ai) [Current pricing and usage](https://clankercloud.ai/pricing)