Sharing a workspace vs sharing a project in Assist

When you collaborate in Assist, you can share your work at two different levels: an entire workspace, or a single project inside it. This article explains the difference between the two and helps you pick the right one for the situation.

Common question: Do I also need to share the workspace?

No, you don't need to share the workspace separately. Sharing a project gives the recipient scoped entry to the workspace it lives in: that workspace will appear in their workspace list, and they can open it — but inside, they'll only see the project(s) you've shared with them. Nothing else.

The rest of the workspace — your other projects, workspace-level knowledge, workspace-level agents, and templates — stays completely private.

Project sharing and workspace sharing are independent actions. Pick the one that matches the level of access you actually want to give.

Quick refresher: workspaces vs projects

Before we talk about sharing, it helps to be clear on what you're actually sharing.

• Workspace — The top-level container for a team or area of work. A workspace holds many projects, plus shared knowledge, agents, and templates scoped to that team.
• Project — Sits inside a workspace and groups the outputs, knowledge, and chats for a specific piece of work — for example, a campaign, a client engagement, or a product launch.

In short: a workspace is the team space, and a project is one piece of work inside it.

Sharing a workspace

What it does: Gives someone access to everything inside that workspace — all projects, all outputs, and all workspace-level knowledge and agents.

When to use it:

• Long-term team members who work across many projects
• Internal collaborators responsible for a whole area of work
• Anyone who needs ongoing, broad access

Good to know:

• It's the broader permission level.
• Any new projects created in the workspace are automatically visible to people who have workspace access.
• This is the right choice when you want someone to be a full participant in the team's day-to-day work.

Sharing a project

What it does: Gives someone access to just that one project — its outputs, project-scoped knowledge, and chats — without exposing the rest of the workspace.

When to use it:

• Clients reviewing or collaborating on a single piece of work
• Freelancers or contractors brought in for one engagement
• Colleagues from other teams who only need to see one project
• Time-limited collaborations
• Anything sensitive where the rest of the workspace should stay private

Good to know:

• The person you shared with reaches the project by entering your workspace — it will appear in their workspace list — but their view inside is scoped: they'll only see the project(s) you've shared with them.
• They won't see other projects in the same workspace.
• They won't automatically get access to workspace-level knowledge or agents — unless those are also shared at the project level.
• It's the safer default when you're not sure how much access someone should have.

Project roles you can assign:

• Admin — Full control of the project, including inviting and re-sharing with others.
• Creator — Can add and edit content in the project, but can't change settings or permissions.
• Viewer — Read-only access; can see the project but not change it.

At a glance: workspace vs project sharing

How to choose

Use this quick guide:

• Use workspace sharing if… the person is part of your team, will work across multiple projects, or needs access to your shared knowledge and agents.
• Use project sharing if… the person only needs to see one piece of work, is external to your team, or the collaboration is temporary or sensitive.

If you're unsure, start with project sharing. It's easier to widen access later than to claw it back.

Common scenarios

• Inviting a client to review one campaign → Project sharing. They see only the campaign, nothing else.
• Onboarding a new team member → Workspace sharing. They get access to everything the team works on.
• Bringing in a freelance designer for a launch → Project sharing on the launch project.
• Adding a manager who oversees all your team's work → Workspace sharing.
• A colleague gives you admin rights on a project in their personal workspace — but hasn't shared the workspace itself. Result: their workspace will appear in your workspace list, and you can open it — but when you do, you'll only see that one project. The rest of their workspace stays hidden, which is exactly the point.

Tips and good to know

• Project sharing and workspace sharing are independent. You don't need to do both — pick the scope that matches the access you want to give.
• Start narrow, widen later. It's easy to upgrade someone from project to workspace access if needed.
• Different people, different projects. You can share the same project with different collaborators at different times — they don't need to know about each other.
• Project sharing doesn't change workspace permissions. Even though the recipient can enter the workspace to reach their shared project, they can't see anything else in it — and adding someone to a single project never gives them broader workspace access.
• Workspace knowledge stays workspace-level. If you want a project guest to use a specific piece of workspace knowledge or an agent, share it with the project too.

That's it — pick the level that matches how much access someone actually needs, and you'll keep things both collaborative and tidy.