A bot is a program that holds a conversation, and Azure Bot Service connects that program to the places where people chat.

Let us start with the basic words. Azure is Microsoft’s cloud platform, a large collection of computers in data centers that you rent when you need them. A bot is a software program that talks with people through text, buttons or speech. You may already have met bots: the chat window on a shopping website that asks “How can I help you?”, or the assistant in a messaging app that reminds you of appointments.

Building a bot involves two different jobs. The first job is the brain, the code that decides what to say in reply. The second job is the connection: making the bot reachable from many chat places, handling identity and security, and passing messages back and forth reliably. Azure Bot Service focuses on the second job. It registers your bot in Azure, gives it an identity, and connects it to channels, which are the apps and websites where users actually type their messages. Your own code, hosted somewhere in Azure, supplies the brain.

Bots are typically built with the Bot Framework SDK, a software development kit, which is a bundle of ready-made code pieces that makes common bot tasks easier. It supports languages such as C# and JavaScript, and also Python and Java in the past. Microsoft’s bot tools have been evolving, and newer offerings such as Microsoft Copilot Studio and the Microsoft 365 Agents SDK now appear alongside them, so always check current guidance before starting a new project.

Bots range from fixed button menus to assistants that understand free text and write their own answers.

Not every bot needs to be clever. Choosing the right style for your problem saves time and money. Here are the common styles, from simplest to most advanced.

A message travels from the user, through a channel and the Bot Service, to your code and back.

Before studying each part, let us look at the whole journey. When a user types a message in a chat app, the app is a channel. The channel sends the message to the Bot Connector, which is the relay service built into Azure Bot Service. The connector checks the bot’s identity and forwards the message, wrapped in a standard format, to your bot’s web address. Your code, running on a hosting service, reads the message, perhaps asks other services for help, and sends a reply back through the same path.

flowchart LR
    U["User"] --> CH["Channel: Teams, web page, other apps"]
    CH --> BS["Azure Bot Service: connector and identity"]
    BS --> BC["Your bot code on Azure hosting"]
    BC --> L["Language and AI services"]
    BC --> D["Storage for conversation state"]
    BC --> BS
    BS --> CH
        

The Azure Bot resource is the official registration that tells Azure who your bot is and where to send messages.

When you create an Azure Bot resource, you register your bot with a few key details. The most important are an identity and a messaging endpoint.

There are different identity types. Single-tenant bots belong to one organization’s directory. User-assigned managed identity bots use an Azure-managed identity, which removes the need to store and rotate secrets. Older multi-tenant bot creation has been phased out for new bots, so current guidance favors single-tenant or managed identity. Since options change, always check the latest documentation when creating a bot.

A channel is a connection between your bot and a chat application, so one bot can serve many audiences.

People use different tools to chat, and a good bot meets them there. Azure Bot Service supports many channels, and you add them to the same bot with a few settings, without rewriting your code for each one. Available channels change over time, so check the current list, but common ones include the following.

Each channel has its own abilities. Some show rich cards and buttons, some show only plain text, and some limit message length. Your bot should be written to work gracefully when a channel cannot show a fancy feature.

Every message and event is wrapped in a standard package called an activity, and each exchange is a turn.

Bots talk in a common format so that every channel looks the same to your code. This format is called an activity. An activity is a small package of information, sent over the web, that says what happened. The most common activity is a message, which holds the text a user typed. But there are other kinds, such as a notice that a user has joined the conversation, a typing indicator, or a custom event.

Each time the bot receives an activity and handles it, one turn of the conversation takes place. A turn is like one round of ping-pong: the user sends something, the bot responds. A conversation is a series of turns, and an important detail is that the bot’s code does not stay running between turns. It wakes up for each activity, does its work and finishes. This is why remembering things between turns needs special care, which we discuss next.

sequenceDiagram
    participant U as User
    participant C as Channel
    participant S as Bot Service
    participant B as Bot Code
    U->>C: Types a message
    C->>S: Sends the message
    S->>B: Delivers an activity over HTTPS
    B->>B: Runs handlers and logic
    B-->>S: Sends reply activity
    S-->>C: Passes reply along
    C-->>U: Shows reply
        

The SDK supplies ready-made pieces so you write only the conversation logic.

The Bot Framework SDK handles tedious work such as checking identity tokens, parsing activities and sending replies. You focus on what the bot should say. Several core ideas appear in every bot built with it.

Because bot code forgets everything between turns, any information it needs later must be saved.

We learned that the bot’s code runs only for each turn. If a user says “my name is Asha” in one turn and asks “what is my name?” in the next, the bot must have saved the name somewhere. This saving is called state management. The SDK provides simple tools for it.

Where the state is stored

State must live in a storage service. Memory storage keeps it only inside the running program, which is fine for learning but lost on a restart and not suitable when several copies of the bot run. For real bots, teams use durable storage such as Azure Blob Storage or Azure Cosmos DB, which survive restarts and can be shared by many copies of the bot.

Dialogs guide a user through a multi-step conversation, one question at a time.

Many tasks need several pieces of information: to book a flight you need the origin, destination and date. A dialog is a reusable piece of conversation that asks for these step by step, checks each answer, and saves progress. A common type is the waterfall dialog, a series of steps where the output of one step flows into the next, like water falling down a stepped waterfall.

flowchart TD
    S["User asks to book a table"] --> Q1["Ask: how many people?"]
    Q1 --> V1{"Valid number?"}
    V1 -- No --> Q1
    V1 -- Yes --> Q2["Ask: which date and time?"]
    Q2 --> V2{"Valid date?"}
    V2 -- No --> Q2
    V2 -- Yes --> C["Confirm details with the user"]
    C --> Y{"User agrees?"}
    Y -- Yes --> D["Make booking and send confirmation"]
    Y -- No --> Q1
        

The SDK includes prompts, ready-made steps that ask for specific kinds of answers such as numbers, dates, choices or yes and no, and that re-ask politely when the answer is not valid. Dialogs can start other dialogs, so you can build a library of small conversations, such as signing in, collecting an address or confirming a payment, and reuse them in many bots.

Principles of good conversation design

Buttons and cards make a bot easier to use than plain text alone.

Typing is slow, especially on a phone. Bots can send more than text to make life easier for users.

Language services help a bot understand free text without a rigid script.

People never type the exact words a programmer expected. They write “I need to change my flight”, “can I move my booking?” or “reschedule please”, all meaning the same thing. Azure offers language services that learn to understand these variations.

Language models can write natural replies, but they need your own data and guardrails to stay accurate.

A large language model is an AI system trained on huge amounts of text that can write human-like replies. Services such as Azure OpenAI make these models available in Azure. A bot can pass the user’s question to a model and relay the answer. But a model on its own does not know your company’s private information, and it can sometimes produce confident but wrong statements.

A popular solution is retrieval-augmented generation, or RAG. In this pattern, the bot first searches your own documents, for example using Azure AI Search, finds the most relevant passages, and gives them to the model together with the question. The model then writes an answer based on those passages, and the bot can show which documents were used. This keeps answers closer to your real information and makes them easier to check.

Bots can act on behalf of a signed-in user and can also start conversations themselves.

User sign-in with OAuth

Some bots must access private data, such as a user’s calendar or order history. For this, the bot needs the user’s permission. Azure Bot Service supports OAuth connections, a standard way of signing in without sharing passwords with the bot. The user is shown a sign-in screen from the identity provider, such as Microsoft Entra ID, approves the access, and the bot receives a token that it can use for a limited time.

Proactive messages

Normally a bot only speaks when spoken to. A proactive message lets the bot start the conversation, for example sending a reminder, a delivery update or an alert. To do this, the bot must have saved a reference to the conversation earlier, and the channel must allow it. Many channels have rules to prevent unwanted messages, so use proactive messages carefully and only where users expect them.

Your bot code needs a place to run, and Azure offers several choices.

The Azure Bot resource only registers and connects the bot. The code itself must run somewhere that exposes a secure web address. Common choices include the following.

Several tools let you try a bot before real users ever see it.

Good testing covers more than the happy path. Try misspellings, very long messages, empty messages, changing your mind halfway, and questions the bot was never designed for. Real users will do all of these.

A bot talks to many people and often touches private data, so security must be designed in from the start.

Watching how people use the bot tells you what to improve.

After launch, the real work begins: finding out whether the bot actually helps. Azure offers several ways to look at a bot’s behavior.

Useful questions to ask of the data

The best bots know their limits and pass the conversation to a person when needed.

No bot can solve everything. Some users are upset, some problems are unusual, and some requests involve money or health that deserve a human’s care. A well-designed bot includes human handoff, a smooth way to transfer the conversation to a live agent along with the history so the customer does not repeat everything.

A bot’s bill is made of several small parts, and the biggest are usually hosting and AI services.

The Azure Bot resource offers a free tier and a standard tier, and the charges for the bot resource itself are usually small compared with the other parts. Pricing details, including how premium channels are charged, change over time, so always check the official pricing page. In practice, your total cost comes from these parts.

Azure offers several ways to build assistants, from low-code tools to full code.

Azure Bot Service with the Bot Framework SDK gives developers full control. But it is not the only route. Microsoft offers other options for different skills and goals, and the lineup changes often, so check what is current.

flowchart TD
    S["Need an assistant"] --> Q1{"Business team, little coding?"}
    Q1 -- Yes --> CS["Consider Copilot Studio"]
    Q1 -- No --> Q2{"Need full control of logic and hosting?"}
    Q2 -- Yes --> BS["Azure Bot Service with SDK code"]
    Q2 -- No --> Q3{"Mainly model-driven answers on your data?"}
    Q3 -- Yes --> AF["Consider Azure AI Foundry tools"]
    Q3 -- No --> BS
        

Habits that experienced teams follow, and traps that beginners often fall into.

Seeing how organizations use bots makes the ideas easier to remember.

No. Azure Bot Service registers your bot, gives it an identity and connects it to channels. The logic of the conversation lives in your own code, hosted on a service such as App Service or Container Apps, or in a low-code tool that you choose.

A channel is a connection between your bot and a place where users chat, such as Microsoft Teams, a website chat window or a messaging app. One bot can be connected to several channels at once.

For bots using the Bot Framework SDK, yes, you need programming skills in a language such as C# or JavaScript. If you prefer low-code, tools such as Microsoft Copilot Studio let business users build assistants with less coding.

Because the bot’s code runs only for each turn, it saves information in state storage, such as Blob Storage or Cosmos DB. On the next turn, it loads that saved information and continues the conversation.

Yes. A bot can call language models, for example through Azure OpenAI. For reliable answers, it is best to ground the model with your own documents using search, add safety filters and keep clear limits on what the bot may do.

Use the Bot Framework Emulator on your computer, the Test in Web Chat tool in the Azure portal, and each real channel you plan to support. Also write automated tests and try unusual, misspelled and unexpected inputs.

The older LUIS service has been retired, and conversational language understanding in Azure AI Language is its recommended replacement. Always check the current documentation, because Azure services change over time.

Microsoft has announced changes to its bot tools and introduced newer options such as the Microsoft 365 Agents SDK and Copilot Studio. The ideas in this guide still apply, but read the latest official guidance before choosing a toolkit for a new, long-lived project.

Azure Bot Service is the connection layer that lets conversational assistants reach users wherever they chat. It registers your bot with an identity, relays messages between channels and your code, and works together with hosting, storage and language services. You have learned the different kinds of bots, how a message travels as an activity during a turn, how the SDK’s adapter, handler and middleware work, and why state must be saved in durable storage. You have also seen how dialogs, cards, language understanding, generative AI with grounding, sign-in, testing, deployment, security, monitoring, handoff and cost fit together.

The best bots start small, do a few things very well, speak honestly about being a bot, protect user data, and keep improving based on real conversations. Because Microsoft’s bot and agent tools are evolving, review the current documentation before you commit to a long project, and design your conversation, data and security carefully so they remain valuable whichever toolkit you use.