Define Access Policies and Visibility Rules

Access policies decide who can see, use, and edit resources. Use Users and Roles to assign tenant-level responsibilities, then apply resource access through agent configuration, teams, and each resource's sharing settings. The practical model is: keep work private while building, share to specific teams for rollout, and use organization-wide access only for approved general resources.

How Access Works

Plan around these rules:

• If an access-controlled resource has no sharing mode, treat it as private.
• The creator can access the resource they created.
• Owner/Admin mode can review organization resources where the user's role allows it.
• Organization access can allow use or write access for everyone in the tenant.
• Team policies can allow Can Use or Can Edit/Write for selected teams.
• External provider permissions still apply. Siesta access does not give a user access to Gmail, Drive, Jira, HubSpot, or another provider if the provider rejects the action.

Where To Configure Access

Resource	Where to review	What to decide
Users	Users and Roles	Who can administer the tenant, invite users, and manage roles
Teams	Teams	Which people share the same operating boundary
Agents	Agents > Access	Private, shared, organization-wide, and team edit rights
Connections	Connections and Organization connection governance	Who can use credentials and which functions run
Workflows	Workflows > Access / Sharing	Which teams can run or edit the workflow
Data and Memory	Data, Memory collections, and collection access	Which agents and teams can retrieve the content
Conversations and recordings	Organization Security and sharing settings	Whether public sharing is allowed

Use vs Edit/Write

Use access lets someone run a resource. Edit/write access lets someone change behavior, prompts, tools, workflow nodes, sharing, or data linkage. Treat edit/write access as an operational responsibility, not a convenience.

Use this default:

• Give Can Use to users who should run the agent or workflow.
• Give Can Edit/Write only to owners who can approve behavioral changes.
• Keep draft agents private until prompts, tools, and data are reviewed.
• Share pilots to one team before organization-wide release.
• Recheck access after every credential rotation, team restructure, or workflow change.

Admin Mode

Admins may use an Admin switch in the application header. With normal mode, the product applies the admin's ordinary user visibility. With Admin mode, elevated organization visibility is used where the role permits it.

Use Admin mode to troubleshoot:

• whether a resource exists,
• whether a user is missing team access,
• whether an agent is private,
• whether a workflow is shared incorrectly,
• whether conversations, tool executions, or data collections need review.

Admin mode does not bypass external provider permissions, private connection ownership, disabled functions, confirmation requirements, or organization security policy.

Troubleshooting Missing Resources

When a user says "I cannot see it":

1. Confirm the organization in the app header.
2. Confirm the user exists and has the expected role.
3. Confirm team membership.
4. Open the resource in Admin mode and check the access policy.
5. Confirm the resource is not still private to the creator.
6. Confirm organization access or team access grants Can Use.
7. If the user needs to edit, confirm Can Edit/Write explicitly.

Troubleshooting Tool Access

When an agent cannot use a connection:

1. Confirm the connection is assigned to the agent as shared or private.
2. For private tools, confirm the current user owns the required private connection.
3. Confirm the organization has not disabled the connection type.
4. Confirm the function is not disabled by organization governance.
5. Confirm the user or team can use the connection.
6. Confirm the external provider credential is still valid.
7. Open Tool Executions to inspect status, arguments, result, and approval state.

Public Access

Public chat, public conversation sharing, public recording sharing, API keys, webhooks, and recordings can be blocked by organization policy. If a page is configured correctly but public behavior fails, check Organization > Security before editing the agent.

For public agents, review:

• public chat enabled at organization level,
• public chat enabled on the agent,
• privacy link,
• feedback and file-upload settings,
• allowed tools,
• prompt boundaries,
• retention and sharing settings,
• whether the widget or public page should use a production agent.

Policy Examples

• Company help agent: organization Can Use, AI Admins Can Edit.
• Support ticket agent: Support Can Use, Support Leads Can Edit, Jira write functions require confirmation.
• Finance reporting agent: Finance Can Use, Finance Admins Can Edit, no organization-wide access.
• Website widget agent: public chat enabled, narrow prompt, reviewed privacy link, limited tools, monitored feedback.
• Experimental workflow: private to creator until read and write Tool Executions are reviewed.

Apply these rules while you configure shared and private connections and before you publish agents or workflows.