Plan Your Organization Setup

Set the tenant identity and plan in Organization General, then review feature availability and reusable content in Organization Settings before broad onboarding. The wider Organization setup also decides how people join, which public features are allowed, how API keys and webhooks are controlled, whether recordings are available, and which identity provider owns user lifecycle.

Step 0: Confirm Platform Readiness

Record the deployment model before treating infrastructure work as an onboarding requirement.

Deployment path	Required readiness check	Done when
Managed Siesta AI service	Confirm the production tenant URL, approved identity provider, service owner, and escalation route. Customer-managed proxy work is not part of this path.	The tenant and sign-in route are available to the named pilot admins.
Customer-controlled or private deployment	Route application traffic through the approved ingress or reverse proxy so the backend is not exposed as a separate public origin unless a documented architecture exception has been approved. Put the required Entra authentication shield in front of the application, and identify the customer IT owner for every customer-side change.	The customer IT change and both controls are live, unauthenticated access is rejected or redirected before the application loads, and the security team has retested the final production route.

Do not send a private deployment for security retest while one of the agreed controls is still pending. Capture the tested URLs, date, owner, result, and any accepted exception. Use the deployment models, network security, and identity and access references for the implementation detail.

Step 1: Choose the Administration Model

The customer business owner chooses how administration is delegated; Siesta AI can explain the trade-offs but should not make the ownership decision on the customer's behalf.

Model	Use when	Decision to record
Centralized	One organization team governs the whole tenant and its business units.	Global Owner and Admin group, request path, and response expectations.
Federated	Each subsidiary, region, or business unit needs its own operational administrators.	Boundaries each local admin may manage and decisions reserved for the global Owner.
Hybrid	Central owners set tenant-wide security and budgets while local admins operate approved teams and pilots.	Central controls, delegated controls, escalation route, and review cadence.

Record one accountable global Owner in every model. For a federated or hybrid model, record each unit, delegated admin, team and data boundary, approved connections, and central approver.

Decisions Before Inviting Users

• Who is the organization owner and who can approve security or access changes.
• Whether administration is centralized, federated, or hybrid, and which decisions are delegated.
• Whether users join by manual invitation, SSO, Microsoft Entra synchronization, approved domains, or a mixed rollout.
• Whether Microsoft Entra users may be created automatically on first sign-in or must receive an invitation.
• Which teams need separate access boundaries for agents, workflows, connections, data, and Memory.
• Which connection types should be allowed tenant-wide and which should be disabled until reviewed.
• Whether public chat, public sharing, webhooks, API keys, and recordings are allowed.
• Which model connections need token limits by organization, team, or user.
• Where admins will review incidents: Tool Executions, Audit Log, conversation history, workflow history, and connected-system logs.

Organization Tabs To Review

Tab	What to decide	Admin note
General	Plan, subscription, organization identity, and token consumption	Confirm the tenant name and billing owner before production rollout
Api Keys	Named keys for external integrations	Keys should map to a real system and owner; delete keys after tests
Settings	Default agent, module availability, apps, extensions, and content imports	Enable only the surfaces approved for the organization
Security	SSO, Entra team sync, sharing, integration policy, AI safety, and retention	Test sign-in before syncing users and treat public sharing as an explicit approval

Identity Setup Pattern

For a small pilot, manual invitations are usually enough. For a managed organization, use SSO and Entra synchronization so user lifecycle follows the identity provider. For multi-domain organizations, document which email domains are allowed before enabling domain-based association.

For Microsoft Entra sign-in, choose the tenant policy explicitly in Organization → Security → User Management:

• Enable Automatically create an account on first sign-in only when every eligible Entra tenant user may join under the agreed default controls.
• Disable it for an invite-only rollout. Each pilot user must then receive an invitation before their first sign-in.

Keep invite-only as a rollout choice, not a universal platform rule. Record who can change the setting and when the policy will be reviewed.

If the rollout uses Microsoft sign-in, Microsoft 365 connectors, Entra group synchronization, or a Siesta AI client app, complete the shared Microsoft Entra ID app registration before testing pilot accounts.

Use this rollout order:

1. Configure SSO metadata and test one admin sign-in.
2. Create a pilot team manually.
3. Invite or sync a small group.
4. Verify their team membership, role, and visible agents.
5. Expand synchronization or invitations only after the pilot users land in the correct organization.

Step 5: Confirm Organization and Security Settings

Organization security controls can block features even when an agent or page is configured. If a user reports that public chat, webhooks, API keys, or recordings are unavailable, check organization policy before debugging the agent.

Feature	Use it when	Keep disabled when
Public Chat	An approved agent should be reachable outside the internal app	Prompts, data, privacy link, or public access are not reviewed
Webhooks	External systems should trigger Siesta AI workflows	There is no API key owner or replay/failure handling plan
API Keys	Backend systems or developer integrations need server-side access	The integration is still exploratory or credentials would be copied into clients
Recordings	Meeting or voice workflows require stored recordings	Retention, sharing, or consent requirements are unclear

Also review Apps & Extensions and the AI security controls in Organization Settings and Organization Security. Record the intended state of Mobile App, Browser Extension, Desktop App, Siesta AI MCP Server, Prompt Shield Filter, LLM Injection Filter, and Content Safety Filter instead of copying another tenant's configuration.

Choose data-retention periods from recovery, support, audit, legal, and governance requirements. If the pilot needs time to establish normal audit volume before a deletion period is finalized, record a temporary decision, an owner, and a review date; do not leave retention undefined by habit.

Token Budget Planning

Token limits are configured on model connections. Use them when a shared model connection powers high-volume agents, workflows, research, or automation. Start with organization-level defaults, then add team or user limits for groups that need a different budget or should be temporarily disabled.

Common Mistakes

• Inviting a full department before SSO and team boundaries are tested.
• Leaving test API keys or webhooks active after a pilot.
• Enabling public chat before the agent prompt, privacy link, uploads, and feedback settings are reviewed.
• Sharing model connections without token limits for high-volume workflows.
• Syncing Entra groups before confirming group ownership and membership.
• Treating Organization Security as a troubleshooting afterthought instead of a launch gate.

After the tenant defaults and any required Microsoft Entra ID app registration are agreed, set the role model, create the pilot teams, and invite their users.