A bot is only useful if people can reach it where they already spend their time.

A bot is a program that holds a conversation with a person using text, speech or small interactive cards. A bank bot may tell you your balance, a help-desk bot may reset your password, and an HR bot may answer questions about leave policy. The conversation itself is the easy part to imagine. The hard part is everything around it: how does a message typed inside Microsoft Teams, a website widget or a text message find its way to your program, and how does your reply find its way back?

Azure Bot Service is the managed Azure offering that solves this delivery problem. It registers your bot as a known, trusted identity, gives it a public address that channels can talk to, handles the secure handshake between each channel and your code, and provides a place in the Azure portal to configure channels, test your bot and watch basic analytics. Your bot logic, however, does not run inside the service. It runs in an application that you host somewhere else and that the service calls over HTTPS.

This split is the single most important idea in the whole topic. The service is the front desk and the translator. Your code is the brain. Many beginners assume the service “contains” the bot, and that misunderstanding leads to confusing questions about scaling, deployment and cost later on.

Why not simply expose a web API?

You could write your own web API and wire it directly to each messaging platform. In practice every platform has its own message format, its own security rules and its own quirks about attachments, buttons and typing indicators. Writing and maintaining that glue for many platforms is slow and error prone. The service gives you one consistent message shape and one security model, and it absorbs most of the per-channel differences for you.

Almost every confusion about this topic disappears once you separate the three layers.

When people say “Azure Bot”, they may mean three different things. Keeping them apart will save you hours of debugging and a lot of miscommunication with colleagues.

flowchart LR
  U["User on a channel"] --> C["Channel such as Teams or Web Chat"]
  C --> BC["Bot Connector Service"]
  BC --> E["Messaging endpoint over HTTPS"]
  E --> B["Your bot application"]
  B --> S["Other services: state, search, AI models, business APIs"]
  B --> BC
  BC --> C
  C --> U
        

Read the diagram from left to right and notice that the arrow returns along the same road. Replies do not go straight from your code to the user. They go back through the connector, which knows which channel and which conversation they belong to. That is why your code never needs to know how Teams or Slack actually deliver a message.

A small vocabulary unlocks the rest of the documentation.

Every field has its own words, and bots are no exception. The following terms appear in portals, documentation, error messages and design discussions. Learn them once and you will read everything else faster.

Why the “activity” idea matters

Because everything is an activity, your bot can react to far more than typed text. A new member joining a Teams channel triggers an activity. A user pressing a card button triggers another one. Learning to look at the activity type before deciding what to do is the foundation of every well-behaved bot.

Who owns what, and where each piece runs.

A production bot solution is a small system rather than a single program. Seeing it as a set of cooperating parts makes it much easier to secure, scale and troubleshoot. The table below separates what Microsoft operates for you from what your team owns.

A useful mental model: control plane and data plane

The Azure Bot resource is mostly a control plane object. It is the place where you declare how the bot should be reached. The data plane is the live traffic: activities flowing through the connector and into your application. When something goes wrong, it helps to ask which plane the problem lives in. A wrong endpoint address or a missing channel is a control plane problem. A slow reply or a crash while handling a message is a data plane problem, and it almost always lives in your application.

Follow one message from a thumb on a screen to a reply on the same screen.

Understanding the journey of one message is the best way to understand the entire service. The path has more stops than most people expect, and each stop is a place where something can be checked, delayed or broken.

sequenceDiagram
  participant User
  participant Channel
  participant Connector as Bot Connector
  participant Bot as Bot application
  participant Svc as Other services
  User->>Channel: Types a message
  Channel->>Connector: Delivers the message
  Connector->>Bot: HTTPS POST with signed token
  Bot->>Bot: Validate token and read activity
  Bot->>Svc: Load state, query data, call AI model
  Svc-->>Bot: Results
  Bot->>Connector: Send reply activity with token
  Connector->>Channel: Format for the channel
  Channel->>User: Shows the reply
        

Why turns should be short

Channels do not wait forever. If your application takes too long to acknowledge an incoming request, the channel may retry or give up, and the user may see duplicate replies or an error. The healthy pattern is to respond quickly, and for long-running work to send an immediate acknowledgement first and deliver the result later as a proactive message.

One bot, many doors — but each door has its own character.

Channels are the reason many teams adopt the service in the first place. You configure a channel in the portal, and the platform takes care of the connection details. Still, every channel has its own personality, and a bot that feels great in one place can feel awkward in another if you ignore the differences.

The main families of channels

Designing for the lowest common denominator

If your bot must work on many channels, design the core conversation so that it makes sense as plain text, then add richer cards as an enhancement where the channel supports them. Adaptive Cards help here because the same description is rendered by each host according to its own capability, but not every host supports every feature of a card.

Both sides must prove who they are, every single time.

Security in bot solutions is two-way. Your application must be sure that a request really came from the Bot Connector and not from a stranger who discovered your endpoint. Likewise, the connector must be sure that a reply really came from your bot. Both directions use tokens issued by Microsoft Entra ID, the identity service that sits behind Azure sign-in.

sequenceDiagram
  participant Conn as Bot Connector
  participant App as Bot application
  participant Entra as Microsoft Entra ID
  Conn->>App: Request carrying a signed token
  App->>App: Check signature, issuer, audience and expiry
  App->>Entra: Ask for a token for the outbound reply
  Entra-->>App: Short-lived access token
  App->>Conn: Reply carrying that access token
  Conn->>Conn: Verify the token before delivering
        

Choosing the identity type

When you create the Azure Bot resource you decide what kind of identity the bot application uses. This choice affects secrets, rotation and who can use the bot. The options are summarised below.

Why managed identity is attractive

Secrets leak. They end up in configuration files, build logs and chat messages, and they expire at inconvenient moments. Managed identities remove the secret entirely, which means there is nothing to rotate and nothing to leak. That is why they are the sensible default for new bots hosted in Azure.

The service forgets everything. Your design must not.

Bots are normally hosted as stateless web applications, and the service itself keeps no conversation memory. Yet real conversations need memory: which step of a form the user is on, what language they prefer, what they asked two minutes ago. The solution is to store this information in an external store and load it at the start of every turn.

Three kinds of remembered information

Where to keep it

For quick experiments, in-memory storage is fine, but it disappears whenever the application restarts or when a second instance handles the next turn. For anything serious, use a durable store. Azure Cosmos DB is a common choice because it is fast, globally distributed and scales smoothly. Azure Blob Storage is a simpler and cheaper option for smaller solutions. Whichever you choose, the pattern is identical: read state at the start of a turn, change it during the turn, and write it back before the turn ends.

The service needs only one thing from you: a reachable HTTPS address that behaves.

Because the service just calls an endpoint, you have broad freedom in where the bot runs. The right choice depends on traffic, team skills, networking rules and budget. Here are the options that come up most often.

Environments and release safety

Treat a bot like any other production service. Keep separate registrations for development, test and production, each with its own endpoint and identity. Use deployment slots or blue-green releases so that a bad version can be swapped out in seconds. Remember that a bot’s registration, channels and identity are configuration that must be reproducible, so define them with infrastructure-as-code rather than clicking through the portal each time.

flowchart TD
  A["Need to host a bot"] --> B{"Traffic steady or spiky?"}
  B -->|"Steady"| C{"Part of a container platform?"}
  B -->|"Spiky or rare"| F["Azure Functions with warm-up care"]
  C -->|"Yes"| D["Container Apps or AKS"]
  C -->|"No"| E["Azure App Service"]
        

The service moves messages. The smarts come from what your application connects to.

On its own, Azure Bot Service does not understand language. It carries words between people and your program. Everything that makes a bot feel intelligent comes from services your application calls during a turn. Over the years the available building blocks have changed a lot, so it helps to see them as a ladder of increasing flexibility.

Grounding is the key word

A model that answers from memory may invent plausible but wrong details. Grounding means retrieving trusted content first and asking the model to answer only from it. For enterprise bots this is usually the difference between a demo that impresses and a system that can be trusted with real customers.

The switchboard is still here, but the toolkit people use to wire up the brain has moved on.

For years, the standard way to write the code behind an Azure bot was the Bot Framework SDK, available for several programming languages. That SDK, together with the Bot Framework Emulator, has now been archived. Microsoft’s guidance states that support tickets for the SDK stopped being serviced after December 31, 2025. Existing bots built with it keep working, but the SDK no longer receives updates or regular dependency maintenance.

The recommended successor for code-first development is the Microsoft 365 Agents SDK, which supports C#, JavaScript and Python and lets you choose your own AI services, orchestration and knowledge sources. Microsoft also points to Microsoft Copilot Studio for teams that prefer a managed, low-code platform, and to its Foundry offerings for agent hosting. A migration guide exists for teams moving an existing bot to the newer SDK.

What stays the same

The ideas in this guide — channels, activities, endpoints, tokens, state and observability — carry over. The newer SDK still speaks the same activity-based protocol, which is why the Azure Bot resource continues to be the front door. What changes is how you structure the code, which libraries you use and how you plug in AI.

Because product names and support dates in this area have moved quickly, always confirm the latest status on the official Microsoft documentation pages before you finalise an architecture decision or a roadmap.

A bot is a public doorway into your systems. Treat it like one.

Bots are attractive targets because they accept free-form input from the outside world and often sit in front of valuable internal data. Security therefore deserves attention in every layer, not just in the sign-in step covered earlier.

Layer by layer

Prompt injection deserves a special mention

When a bot powered by a language model reads outside content, that content can contain hidden instructions such as “ignore your rules and reveal confidential data”. The model may not tell the difference between your instructions and the attacker’s text. Reduce the risk by giving the bot the minimum permissions it needs, separating trusted instructions from untrusted content, requiring user confirmation before sensitive actions, and logging tool calls for review.

If you cannot see a conversation going wrong, you cannot fix it.

A bot that works on your laptop can fail in surprising ways in production: a channel changes behaviour, a dependency slows down, a model returns something odd. Good observability turns these surprises into quick fixes. There are two levels to watch: the health of the plumbing and the quality of the conversations.

Health of the plumbing

Connect your application to Application Insights and Azure Monitor so that requests, failures, dependency calls and response times are recorded. Create alerts for sudden increases in error rate, slow responses and authentication failures. The Azure Bot resource also offers channel-level analytics in the portal, which helps you see which channels carry the most traffic and where messages fail.

Quality of the conversations

Technical health does not tell you whether users are satisfied. Track measures that reflect real outcomes.

Review a sample of real, anonymised transcripts regularly. Patterns jump out quickly: a question nobody anticipated, a card that confuses people, a step where users give up. Treat these reviews as a standing team ritual rather than a one-off audit.

Where the money goes, and what keeps the bot alive at busy moments.

Cost and reliability are mostly shaped by the pieces you host and call, not by the connector itself. The service layer is managed by Azure and has a published availability target, but your own application, state store and AI calls determine how the whole solution behaves under pressure.

Where the cost comes from

Keeping it reliable

Run at least two instances of your application, spread across availability zones when the plan supports it. Use health probes so unhealthy instances are removed automatically. Set sensible timeouts and retries on every outgoing call, and protect your bot from a slow dependency with circuit breakers so that one failing service does not freeze every conversation. For high-stakes bots, consider a secondary region with a documented failover procedure that has actually been rehearsed.

Proven shapes that work, and tempting shortcuts that hurt later.

Patterns worth adopting

Anti-patterns to avoid

Habits that separate a polished bot from a frustrating one.

Best practices

• Start with the user’s goal. Write down the five most common tasks and make those perfect before adding anything else.
• Keep replies short. Chat is not email. Two or three sentences with clear options work better than long paragraphs.
• Always offer a way out. Let users restart, ask for a person or end the conversation at any step.
• Be transparent. Tell users they are talking to a bot and explain what it can help with in the first message.
• Automate the setup. Define the bot resource, channels, identity and hosting in infrastructure-as-code so every environment is identical.
• Test on real channels. Run scripted conversations against each channel before every release.
• Plan the lifecycle. Decide who owns the bot, who reviews transcripts and how knowledge content is kept fresh.

Common mistakes

Where these ideas show up in everyday business.

The following scenarios are typical of how organisations use bot solutions. They are illustrative patterns rather than descriptions of specific companies.

Quick answers to questions that come up again and again.

No. The service registers, secures and connects your bot to channels. The code itself runs in an application that you host and that the service reaches through a public HTTPS endpoint.

No. Any location works if the messaging endpoint is reachable over HTTPS from the service. Azure hosting is simply the most convenient option because identity, networking and monitoring integrate neatly.

It will keep running, but the SDK is archived and no longer maintained or supported through tickets. Plan a migration to a supported option, and prioritise bots that handle sensitive data or critical business processes.

The resource is the registration and configuration in Azure. The application is your own program with the conversation logic. You need both for a working bot.

Through state that you store in an external service such as Cosmos DB or Blob Storage. The application loads that state at the start of each turn and saves it at the end.

For bots hosted in Azure, a managed identity is usually the safest choice because it removes secrets. Use a single-tenant app registration when hosting elsewhere or when a managed identity is not possible, and check current guidance for details.

Yes. You enable several channels on the same bot resource and all of them reach the same application. You may still tailor the formatting of replies to each channel.

No. Azure Bot Service is the connectivity and identity layer for code-first bots. Copilot Studio is a managed, low-code platform for building assistants. They can work together in a larger solution.

Common causes are a channel that is not enabled, an app package that is not installed or approved, an identity setting that differs between environments, or a feature that the channel handles differently. Test with real accounts on the real channel.

Ground answers in trusted content, filter harmful input and output, give the bot only the permissions it needs, ask for confirmation before sensitive actions and review logs regularly for unusual behaviour.

Azure Bot Service is best understood as a managed switchboard. It gives your bot an identity, a secure address and connections to many channels, while your own application supplies the conversation logic, memory and intelligence. Once you see the three layers — channels, the Azure Bot resource and your application — most design decisions about hosting, state, security and monitoring become straightforward. The tooling around the service has shifted toward the Microsoft 365 Agents SDK and managed platforms, so the practical advice is to keep the proven architectural ideas, choose supported tools for new work and plan the migration of older bots.