Share a reviewed App with the intended people.

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.

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 it with a small example.

Before you use 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.