Visibility and Sharing

Every project, workflow, and trigger you create starts private -- visible only to you. Sharing is always opt-in, and you control both the audience and the access level.

The three tiers

Tier	Who can see it
Private (default)	Just you, the creator
Shared	You + specific teammates you invite by name or email
Org	Everyone in the organization (read-only for non-creators)

The same three tiers apply to projects, workflows, and triggers -- but each resource is shared independently. Sharing a project does not automatically share its workflows.

Why three tiers?

• Private is the safe default. Anything you're still figuring out stays out of teammates' way.
• Shared is for collaboration with specific people -- a colleague who's helping debug, a manager who needs to watch the runs.
• Org is for resources the whole organization should benefit from -- a chatbot project everyone consults, a workflow anyone can trigger.

Most working resources stay private. You don't need to share something to use it yourself.

Sharing a project

Project sharing grants access to the project's container: its documents, its team and agent structure, its chatbot (if enabled), and the project-level activity feed. It does not cascade to the workflows or triggers inside -- each of those is shared separately.

Steps

1. Open the project's detail page.
2. Click Share in the page header to open the Share drawer.
3. To share with specific people, type the teammate's email or name and click Invite. Repeat for as many people as you need.
4. To make the project visible to the whole org, switch the visibility selector to Organization.

# TODO screenshot: project Share drawer with two members invited and the visibility selector visible

The recipient sees the project on their own Projects page immediately. They can browse documents and team structure, but they cannot edit anything in the project unless they're also the creator of that specific workflow or trigger.

Revoking a share

In the same Share drawer, click the X next to a teammate's name. Their access ends immediately. If you flip the project back to Private, all org-wide visibility ends at the same moment.

Sharing a workflow

Workflow sharing is the most common collaboration action because workflows are the things that run. Workflows have one extra knob: a view mode that controls whether the recipient sees the builder or just a Run button.

See the dedicated page: Sharing a Workflow.

Sharing a trigger

Triggers (schedule, webhook, app-event) share the same three-tier model as workflows. Sharing a trigger lets a teammate see the trigger's history, status, and recent fires.

A trigger fires the workflow as the trigger's creator -- not as whoever shared it. So if Alice creates a schedule trigger and shares it with Bob, the run executes on Alice's credentials. Bob sees the runs happen; he doesn't authorize them.

Steps

1. Open the workflow's Runs & Triggers tab.
2. Click the trigger card to open it, then click Share.
3. Invite teammates the same way as for projects.

# TODO screenshot: trigger Share drawer

Who sees what -- the cheat sheet

You are...	And the resource is...	You can see it?	You can edit it?
The creator	Anything	Yes	Yes
Invited via Share	Private/Shared	Yes	No
A regular member	Org-visible	Yes (read-only)	No
A regular member	Private/Shared (not invited)	No	No
An admin	Private/Shared (not invited)	Yes (audit-view, read-only)	No
An owner	Anything	Yes (audit-view)	No (unless creator)

The key insight: only the creator can edit. Admin and org access are read-only.

Learn more

• Sharing a Workflow -- Inspector vs Runner mode
• Templates and the Org Marketplace -- when to share vs when to export
• Roles: Member, Admin, Owner