Overview

Leena AI uses a multi-environment setup to give your team a safe, structured path from building an AI Colleague to deploying it for your employees. Instead of configuring everything directly in the bot your employees interact with, you work through a series of logically separated environments — each serving a distinct purpose in the deployment lifecycle.

This guide explains what each environment is, how they relate to one another, what you can and cannot do in each, and how data flows between them.

Important clarification: All environments — Staging, UAT, and Production — run on the same Leena AI production infrastructure. An environment is not a separate server or deployment. Each environment is simply a separate bot instance (with its own unique Bot ID) that carries an environment label. The "Staging" environment for your deployment has no relation to Leena AI's internal staging environment used for testing platform features before release.

---

---

Bot Clusters

Your Leena AI deployment is organized into a Cluster. A cluster is a group of up to three bot instances, each tagged with an environment label:

Every environment within a cluster has its own unique Bot ID. All three bots run on the same infrastructure; the environment label simply determines how each bot is used in your deployment lifecycle and what restrictions apply to it.

Environment setup is handled by the Leena AI team. The creation of your cluster, provisioning of environment bots (Staging, UAT, Production), and the initial configuration of Bot IDs are done by the Leena AI team during your onboarding. You do not need to set up environments yourself. Once your environments are provisioned, you can start building in your Staging bot and follow the promotion workflow described in this guide.

Key concept: A cluster is the boundary within which data can be migrated. You can only migrate assets (like Workflow Apps) between bots within the same cluster.

---

What Is an Environment?

An environment in Leena AI is a bot instance with a role. It is identified by a unique Bot ID and tagged with one of three environment labels: staging, uat, or production.

All environment bots share the same platform capabilities — the same AI engine, the same integration framework, the same dashboard. What differs is:

• The purpose each bot serves in your workflow (building vs. testing vs. live)
• What editing actions are allowed (content editing is restricted in higher environments)
• How Knowledge Management content is managed (each environment has its own independent knowledge base, and tested KM changes are cloned up to higher environments)

Because all bots run on the same infrastructure, a Tool or Workflow tested in your Staging bot will behave identically in your Production bot — provided the same integrations, credentials, and configurations are in place.

---

Environment Definitions

Staging

Purpose: This is where your team builds and configures the AI Colleague setup — creating AOPs, setting up Tools, building Workflow Applications, connecting integrations, and setting up Knowledge Management content.

What you do here:

• Create and configure AI Colleagues and AOPs
• Build and test Workflow Applications
• Set up integration connections (Workday, ServiceNow, Jira, etc.)
• Author and test Tools (API, Workflow, MCP)
• Set up Knowledge Management connections, create or upload articles, and adjust KM settings — Staging has full KM access
• Test everything using the Workbench before promoting

Restrictions:

• Not connected to employee-facing channels — content here is not visible to employees
• Knowledge Management content is not copied into Staging from other environments. Connect the sources you need or upload articles here, then clone tested changes up to UAT
• This environment is intended for iterative development — expect frequent changes
• Full employee sync is not required in Staging. Add a limited set of test employees to verify flows and configurations — save full employee directory sync for Production

---

UAT (User Acceptance Testing)

Purpose: Where business stakeholders validate the AI Colleague's behavior before it goes live.

What you do here:

• Configure and test Knowledge Management connectors (SharePoint, Confluence, ServiceNow KB, etc.) — clone them from Staging, or set them up directly in UAT. You can use the same credentials as Production (for example, the same SharePoint tenant or ServiceNow instance) to validate new content sources, permissions and KM features before employees see them. Read more about KM environments.
• Test end-to-end workflows with realistic scenarios
• Validate Knowledge Management article responses
• Confirm that integration connections work with target environment credentials
• Run regression testing on AOP behavior and tool execution
• Verify audience-scoped configurations reach the right user groups
• Sign off on readiness for production

Restrictions:

• UAT is a validation environment, not a build environment — AI Colleagues, AOPs, and Tools should be built in Staging first and then recreated or migrated here
• Production KM changes do not flow down to UAT. Make sure UAT has the content you want to test against — to bring in Production content, set up the same connection in UAT and run a sync
• Full employee sync is optional in UAT. Add a representative subset of employees to validate end-to-end flows across departments and roles — full directory sync can wait until Production

---

Production

Purpose: The live bot serving your actual employees. This is the bot they interact with through Slack, Microsoft Teams, the web widget, or any other configured channel.

What happens here:

• Employees query the AI Colleague for help
• Workflows are initiated and processed
• Knowledge articles are served
• Tickets are created and routed
• Integrations execute real AOPs/Tools (leave requests, IT tickets, payroll queries, etc.)
• Tested KM connections, articles and settings are brought in from lower environments using Clone from another environment
• Full employee sync is required in Production. Ensure the complete employee directory is synced and validated before go-live to guarantee all employees have access from day one

Restrictions:

• This is your live environment — changes should only be made here after thorough testing in lower environments
• KM changes made here — including deletions — stay in Production. They are not copied to UAT or Staging

---

How Data Flows Between Environments

Different types of data move between environments in different ways. Understanding this helps you know what to expect when working across Staging, UAT, and Production.

Knowledge Management: Independent per Environment

Each environment — Staging, UAT and Production — has its own independent knowledge base. A sync, edit or deletion in one environment never changes another. Each environment manages its own:

• Connections — credentials, selected content, filters and auto-sync schedules
• Articles — manually created or uploaded articles, and the articles each of its connections syncs
• Settings — bot settings, dashboard settings and article visibility

Tested KM changes move up the promotion order: Staging → UAT → Production. If your organisation also has a Pre-Prod environment, it sits between UAT and Production. Open the higher environment and use Clone from another environment to copy from an environment below it:

Cloning copies — the source environment keeps everything it has. Nothing can be cloned downward: to get Production content into a lower environment, set up the same connection there and run a sync.

For step-by-step instructions, refer to Environments in KM (Production vs UAT vs Staging).

AI Colleague Configuration: Must Be Set Up Per Environment

Most of the AI Colleague stack — AICs, AOPs, tools, Workflow Applications, and Integration connections — does not automatically flow between environments. These must be explicitly migrated or recreated in each environment:

• Workflow Applications — Migrated using the built-in App Migration feature
• Knowledge Management connections, articles and settings — Cloned from a lower environment into a higher one using Clone from another environment; see Knowledge Management: Independent per Environment above
• AI Colleagues and AOPs — Must be created manually in each environment (guided migration coming soon)
• Tools — Vary by type; see the AIC Migration Guide for details
• Integration connections — Must be set up independently per environment with environment-specific credentials

Some promotions — such as NLU model and intent data overrides — are handled by the Leena AI team as part of your go-live process.

---

Key Things to Know

Audiences are environment-specific. Even if two audiences share the same name across your Staging and Production bots, they have different internal IDs. When setting up AOPs or tools with audience restrictions in a new environment, always select audiences from that environment's list — don't assume they carry over.

KM changes stay in the environment where you make them. This includes deletions — deleting a knowledge article removes it only from that environment, so delete it in each environment where it exists. KM auto-sync schedules are never cloned either: check them in every environment, and keep auto-sync off in lower environments unless you need it.

The dashboard shows which environment you're in. A color-coded environment indicator is always visible in the dashboard so you can confirm which bot you're working on before making changes.

---

Frequently Asked Questions

Are the environments on different servers?
No. All environment bots — Staging, UAT, and Production — run on the same Leena AI production infrastructure. An "environment" is simply a separate bot instance with a different Bot ID and an environment label. There is no separate server or deployment for each environment.

Is my "Staging bot" related to Leena AI's staging environment?
No. Your Staging bot is part of your live deployment — it's a bot you use for building and configuring before promoting to your Production bot. Leena AI's own staging environment is a completely separate system used for testing platform updates before they are released. The two are unrelated.

How many environments do I need?
At minimum, you need Staging and Production. UAT is strongly recommended for any enterprise deployment. Discuss your requirements with the Leena AI team during onboarding — they will provision the right set of environments for your deployment.

Can I have multiple clusters?
Yes. Large organizations often have separate clusters for different regions, divisions, or use cases. Each cluster has its own independent set of environment bots. Talk to the Leena AI team if you need additional clusters provisioned.

Can I migrate assets between clusters?
No. Migration (for Workflow Apps, overrides, etc.) is restricted to bots within the same cluster. For cross-cluster setups, assets must be manually recreated.

What happens if I skip UAT?
You can technically promote directly from Staging to Production, but this is strongly discouraged. UAT is where stakeholders and test users validate AI Colleague behavior, Knowledge Management content, permissions and audiences before employees see them. Without it, those changes meet real users for the first time in Production.

Can I set up KM connectors in Staging?
Yes. Since 6 October 2026, every environment — including Staging — has full Knowledge Management access, and each one is an independent knowledge base. Content is not copied into Staging from higher environments: connect the sources you need in Staging or upload articles directly, then clone tested changes up to UAT and Production.

Does Production KM content still flow down to UAT and Staging?
No. The automatic copy from Production was switched off on 6 October 2026 and cannot be turned back on. To bring Production content into a lower environment, set up the same connection there and run a sync. KM settings and manually added articles have to be updated in the lower environment by hand.

Can I use my production integration credentials in Staging?
Technically yes, but it's not recommended. Using production credentials in the Staging bot means test actions (like creating tickets or submitting leave requests) would execute against your live systems. Always use sandbox or test credentials for lower environment bots where possible.

This guidance applies to integrations that take actions. Knowledge Management connectors are different — they sync content into KM — and connecting a lower environment to the same source as Production (for example, the same SharePoint tenant) is a supported way to validate content, permissions and KM features before go-live. If more than one environment auto-syncs the same source, keep auto-sync off in lower environments or stagger the schedules to limit load on that system.

Since all bots run on the same infrastructure, will my Staging bot's testing affect Production performance?
No. Each bot instance is fully isolated at the data level — they have separate conversations, separate configurations, and separate user sessions. Activity on your Staging bot does not affect your Production bot's performance or data in any way.