Admin Guide
Plan, launch, and govern Siesta AI for an organization: identity, teams, access, connections, tools, agents, workflows, monitoring, and audit evidence.
Use this guide as an operating manual for running Siesta AI inside an organization. It is written for owners and admins who need to make access, identity, connection, tool, agent, workflow, and audit decisions before teams start using production assistants.
The important rule is simple: configure the tenant before inviting broad usage. Siesta AI can keep resources private, share them with selected teams, allow organization-wide use, require write permissions, disable connection types, force tool functions into confirmation mode, and record operational changes in audit logs. Admin work is the process of choosing those defaults deliberately.
Browse by Outcome
Organization Setup
Confirm platform readiness, choose the administration model, configure identity, and onboard the pilot team.
Adoption & Rollout
Choose a useful first initiative, set expectations, assign ownership, and run an executable kick-off.
Build & Scale
Create one private pilot agent, add a governed data pack, test it, and share it safely.
Maintenance & Monitoring
Review usage, cost, limits, data, tool executions, audit evidence, and operational improvements.
What Admins Actually Own
| Area | Admin decision | Failure if skipped |
|---|---|---|
| Organization | Plan, API keys, SSO, security switches, public features, recordings, and Entra sync | Users join the wrong way, public features are enabled without review, or keys remain unowned |
| Teams & users | Who belongs to each access boundary and who can administer it | Agents and connections get shared too broadly |
| Connections | Which providers are enabled, who owns credentials, and which functions need confirmation | Agents can read or write through the wrong external account |
| Data | Which systems are authoritative, what is ingested, who can use collections, and how sources are tested | Stale, confidential, or irrelevant content becomes agent context |
| Access policies | Private, team, organization, use, and edit/write permissions | Users cannot find resources, or too many users can change them |
| Agents & workflows | Production behavior, data, tools, prompts, approvals, and rollback path | Workflows change records or agents answer from the wrong context |
| Monitoring | Tool Executions, Audit Log, conversations, feedback, usage, and token limits | Incidents have no clear owner or evidence trail |
Backend Rules To Plan Around
- Access-controlled resources are effectively private unless an access mode or policy shares them.
- Creators can access their own resources; Owner/Admin mode can review organization resources where the role allows it.
- Team access distinguishes use from write/edit. Give edit rights only to people who can safely change prompts, tools, workflow logic, or access.
- Connection type governance can disable a provider for the whole organization.
- Function governance uses the strictest effective setting: enabled, enabled with confirmation, or disabled.
- REST and MCP tools can expose custom functions. Treat their schemas, headers, and write behavior as production contracts.
- Token limits are managed per model connection at organization, team, and user level.
- Tool executions record function status and approval state. Audit logs record configuration changes with entity, user, timestamp, correlation ID, and changed properties.
Admin Onboarding: Steps 0–8
Use this as the shortest path from an unconfigured tenant to one tested pilot. Each row has an observable completion condition; the linked pages contain the detail.
| Step | Action | Done when | Continue to |
|---|---|---|---|
| 0. Platform readiness | Identify managed SaaS or customer-controlled/private deployment and complete only the infrastructure gates that apply. | Managed SaaS is recorded as not requiring customer proxy work, or the private production route, pre-app authentication, customer IT change, and final security retest have passed. | Choose the administration model |
| 1. Governance | Choose centralized, federated, or hybrid administration and name the global Owner. | The customer has approved an administration matrix with delegated boundaries and escalation owners. | Choose roles |
| 2. Roles | Use Owner, Admin, Editor, and User deliberately; create a narrower custom role when required. | Every pilot duty maps to a role, and a Private Builder can create without receiving sharing or tenant-administration permissions. | Design teams |
| 3. Teams | Create the pilot access boundary before sharing agents, data, or connections. | The pilot team has an owner, intended members, and a documented resource boundary. | Choose the invite policy |
| 4. Invites | Choose auto-registration or invite-only, then invite or provision a small pilot group. | Pilot users sign in to the correct tenant with the expected role and team; pending, expired, or revoked invitations are resolved. | Confirm organization settings |
| 5. Organization and security | Review feature availability, apps, extensions, SSO, sharing, integration policy, AI filters, and retention. | The intended state and owner of every applicable control are recorded, tested, and approved. | Configure connections and limits |
| 6. Connections and limits | Configure the first model connection, credential ownership, sharing boundary, and broad-to-specific token limits. | A safe read works, the credential and rotation owner are known, and organization/user/model budgets are set. | Create the pilot agent |
| 7. Pilot agent | Create one agent from scratch with Medium reasoning, default model parameters, a focused system message, required skills, and only relevant tools. | The private agent follows its scope, refuses prohibited actions, and exposes only the intended tools; data-dependent evaluation continues in Step 8. | Add the pilot data pack |
| 8. Pilot data | Create one coherent private collection, ingest representative content, inspect processing evidence, attach it, and test retrieval. | Expected files and chunks are usable, known answers are traceable, missing evidence is admitted, conflicting evidence is surfaced, and the private pilot is ready for safe team sharing. | Monitor the rollout |
The onboarding path does not replace adoption planning. Before committing production time, use Find Initiatives, Prioritize Initiatives, and Enterprise Kick-off to confirm that the pilot has a useful outcome, owner, audience, and decision deadline.
After Step 8, add REST, MCP, Power BI, or other live tools only when the tested use case needs current external state or an external action. Keep that work in the advanced tools and MCP branch.
Common Admin Problems
| Problem | Check first | Usually fixed by |
|---|---|---|
| A user cannot see an agent or workflow | Team membership, access mode, organization access, and team policy | Add the user to the right team or grant team Can Use access |
| An agent cannot call a tool | Connection sharing, organization connection policy, function access mode, and private connection ownership | Share the connection, enable the provider, or assign the user's private connection |
| A write action waits for approval | Function access is set to confirmation | Approve the execution, or intentionally lower the function access if the action is safe |
| A shared model connection burns too many tokens | Connection token limits and agent/workflow usage | Set org/team/user limits and split high-volume automations into a reviewed connection |
| SSO users land in the wrong tenant | SSO config, domain linking, invitation state, and Entra group sync | Fix SSO metadata/domain ownership before inviting more users |
| A workflow changed the wrong record | Arguments recorded in Tool Executions, workflow node parameters, previous node output, and approval status | Pause sharing, tighten parameters, require approval, and retest |
| Public chat or sharing is unavailable | Organization Security feature flags | Enable the feature intentionally, then review privacy and retention settings |
Rollout Phases
Start with one pilot team, one or two approved connections, and one production-quality agent. Do not start with every integration, every department, and organization-wide access. After the pilot, expand by team and reuse the same review loop: access, tools, approvals, test data, Tool Executions, audit evidence, and owner sign-off.
Move advanced work into a second phase: REST/MCP tool design, external API automation, workflow webhooks, realtime agents, detailed token economics, evaluation loops, and connection-specific governance.
Admin Readiness Checklist
- Identity: SSO, manual invitations, Entra sync, and approved domains have a clear owner.
- Teams: every production team has a business owner and a defined access boundary.
- Connections: credentials are named, scoped, and owned; unused keys are deleted.
- Data: each production collection has an owner, approved selectors, tested chunks, an access policy, and a sync/retirement plan.
- Function approvals: write, delete, publish, permission, and customer-data actions require confirmation unless explicitly approved.
- Agents: every production agent has a purpose, prompt, model connection, data sources, tools, access policy, and test conversation.
- Workflows: write-capable workflows are tested on safe records and have a rollback path.
- Monitoring: admins know where to review Tool Executions, Audit Log, conversations, feedback, usage, and token limits.