An assistant's visibility and its shared access decide who can find it, use it, and manage it. These settings let you keep work private while still collaborating across your organization.You manage both from two places: Visibility under Advanced on the assistant's page, and the Access Control window (Edit Access in the assistant's menu), which has three tabs:Direct Access: users and teams added to this assistant. The creator is listed with the role Owner.
Inherited Access: users and teams who get access through the assistant's project. The Scope column shows where the access comes from.
Associated Workflows: workflows that use this assistant.
Visibility#
Every assistant is either Private or Public. You set this under Advanced > Visibility in Staging, and it takes effect when you deploy.Private#
| Attribute | Details |
|---|
| Visibility | Only you and those with access can view the assistant. |
| Who has access | The assistant's owner, Global Admins, and users who were given access directly, through its project, or through a team, as long as they hold a Permission Set that grants the relevant access. |
| Purpose | The default for new assistants. Use it while you build an assistant or for sensitive work. |
Private is the default visibility for all new assistants.
Public#
| Attribute | Details |
|---|
| Visibility | Anyone within your organization can access the assistant. |
| Purpose | Assistants meant for wide use, such as help desks or shared knowledge bases. |
| Sharing | Only Public assistants can be shared from the Share menu: Copy view only link, Copy view & edit link, Embed this assistant, and Open public link. |
Users also need a Permission Set that grants view permission on assistants. Make sure a Public assistant's configuration contains no sensitive or confidential information.
Permission propagation and collaboration#
Access to an assistant is often inherited from higher levels in the hierarchy, which makes it easy to manage large groups of users.Inherited access#
| Inheritance type | Details |
|---|
| Project inheritance | Users and teams added to a project as a Member or Admin get that same level of access to every assistant in the project. |
| Team assignment | Giving a team access to a project or an assistant shares that access with everyone in the team. |
Access inherited from a project or a team doesn't grant its members access automatically. Each member gains access only if they hold a Permission Set that allows the action on assistants in the projects they have access to or assistants shared with their teams.Member: Lets a user view the assistant if their Permission Set grants view on assistants shared with the user's teams or on assistants in the projects the user has access to. It is capped at view: a member can't edit, delete, or deploy the assistant, even if a Permission Set would otherwise grant those actions.
Admin: Lets a user view, edit, delete, or deploy the assistant, action by action, for each action their Permission Set grants on assistants shared with the user's teams or on assistants in the projects the user has access to.
Collaborative editing#
Users with the Admin role, assigned directly or inherited, can change an assistant's settings. This allows:| Benefit | Details |
|---|
| Shared responsibility | Several team members can manage an assistant's knowledge, tools, and settings together. |
| Security | Only users with Admin access can take destructive or sensitive actions, such as deleting the assistant or changing its configuration. |
| Flexibility | Access can change as a project's needs evolve. |
Use cases#
Confidential assistant: Keep an assistant that answers questions about salary bands Private and give direct Member access only to the HR managers who need it.Company-wide help desk: Make an IT help assistant Public so everyone can use it, and give the IT team Admin access through its project so any of them can update it.Shared ownership: Add two colleagues as Admin so the assistant still gets updates when its creator is away. 