Skip to main content

Shared Views and Public Apps

Some workspaces are only for the internal team. Others need an external edge.

You may need:

  • a public-facing view
  • a partner dashboard
  • a customer intake flow
  • a read-only portal
  • a limited external action such as submitting a form or checking status

Shared views are how you expose only the part of the workspace that should be visible outside the workspace.

What a shared view is​

A shared view is a curated external view built from the workspace.

It is not the full workspace. It is a selected slice of it, with its own access rules.

That means you decide:

  • which views are included
  • which one is the landing view
  • who can open it
  • what actions, if any, are allowed

Who shared views are for​

Common audiences include:

  • customers
  • partners
  • external collaborators
  • anonymous public visitors

Each of those should have different access expectations. A public read-only portal is very different from a partner view that can trigger a workflow action.

What to decide before sharing​

Before you create a shared view, decide:

  • what information should be visible
  • whether the view is read-only or interactive
  • whether any tools behind the view can create or change data
  • who should be able to open it

That last point matters because sharing is both a product decision and a security decision.

What a safe shared view looks like​

A safe shared view is:

  • focused on one clear purpose
  • narrow in what it exposes
  • clear about what actions are possible
  • easy to revoke or disable

If a shared view looks like a disguised copy of the full workspace, it is too broad.

Public access versus restricted access​

There is a big difference between:

  • sharing with a known group of people
  • making something publicly accessible

Public access is easier for the audience, but it raises the standard for what the view is allowed to show or do.

If a shared view is public and can trigger write actions, you should treat that as a high-risk configuration and review it carefully.

What to review before publishing​

Before you publish a shared view, check:

  • whether the right view is the landing page
  • whether the visible data is appropriate for the audience
  • whether any write or execute actions are exposed
  • whether the audience is private, limited, or public
  • whether the view can be disabled quickly if needed

Example​

Imagine your workspace handles service requests.

Inside the workspace, the team may use:

  • a triage queue
  • an internal operations dashboard
  • a workflow activity feed

Outside the workspace, the customer may only need:

  • a simple intake form
  • a status page
  • a follow-up confirmation screen

That external slice should be a shared view, not full workspace membership.

What good sharing feels like​

When sharing is done well:

  • the internal team keeps the full workspace
  • external people get only the view they need
  • access is easy to understand
  • risky actions remain deliberate

That is the right standard for public apps and shared views built on top of a workspace.