Bots & Custom Apps
Building your first Microsoft Teams bot
The first bot most people build for Microsoft Teams is an echo bot. It repeats what you typed. Everyone claps once. Nobody uses it again. Useful bots answer a real recurring question without making a human dig through SharePoint at 4:50 p.m.
I am Priya Shah. I consult on Microsoft Teams automation. This tutorial is independent and educational. I am not a Microsoft partner, and this is not an official Microsoft guide. Build only what your tenant policies allow. Do not treat this as permission to bypass admin consent.
Below is how I walk a team through their first real bot: a FAQ bot backed by a SharePoint list. High level on Azure Bot and Teams Toolkit. Clear on when a bot beats a flow. No exploit talk, no malware talk, no clever ways to sneak past governance.
When a bot beats a flow
Power Automate flows shine at event-driven work. A file arrives. A form submits. An approval finishes. A scheduled reminder fires. Flows are excellent doorbells and conveyor belts.
A bot shines when a person initiates a conversation and expects a back-and-forth in chat. “What is the laptop refresh policy?” “Where is the brand template?” “Who approves vendor NDAs?” Those questions arrive irregularly, with messy wording, and they want an answer in the same thread.
If your automation has no human prompt and just moves data when something happens, build a flow. If humans keep asking the same class of question in Teams and resent hunting for the SharePoint page, consider a bot.
Bots also help when you need a consistent command surface. Slash-like intents, buttons, adaptive cards with choices. Flows can post cards too, but a bot feels like a helper you can reopen later.
Cost and maintenance differ. A flow can be lighter to own for simple reactions. A bot brings app registration, hosting, versioning, and admin consent. Do not build a bot because it sounds advanced. Build it because the interaction model fits.
A quick gut check I use: if the user must type a request to start the useful work, lean bot. If the system should notice an event and act without being asked, lean flow.
High-level pieces: Azure Bot, Teams Toolkit, registration
At a high level, a Teams bot is an identity plus an endpoint plus Teams packaging.
You register an application in Microsoft Entra ID so Teams and your backend share a trust relationship. You create a bot resource that knows how to receive activities from Teams channels and personal chats. You host code that responds to those activities. Teams Toolkit in Visual Studio Code scaffolds a lot of this for local development and packaging.
I am staying high level on purpose. Exact portal clicks change. The concepts do not. You need an app registration, a bot channel registration for Microsoft Teams, a publicly reachable HTTPS endpoint for production, and a Teams app manifest that points to your bot.
Locally, Toolkit can tunnel and sideload into a development team if your tenant allows sideloading. Production usually means an admin publishes the app to your org catalog or grants consent for the permissions you request.
Do not skip the manifest details. Name, description, icons, and the scopes you request will be read by admins who decide whether employees can install the app. A vague description that says “productivity helper” gets delayed. A clear description that says “answers policy FAQs from the Contoso HR SharePoint list” gets reviewed faster.
Also plan environments. Dev bot and prod bot should not share secrets. I have watched a Friday deploy overwrite a Monday experiment because someone reused one app ID everywhere.
Admin consent is not optional paperwork
Your bot will request permissions. Some are delegated. Some are application permissions. Admins decide what is acceptable.
Ask early. Bring a one-page note: what the bot reads, what it writes, where answers come from, who can use it, and how you rotate secrets. Admins are not villains. They are the people who get the ticket when a bot posts nonsense into a company-wide team.
If your FAQ bot only needs to read a SharePoint list under a managed identity or a constrained app permission, say so. Least privilege is easier to approve than “full access to everything just in case.”
Sideloading in a sandbox team is fine for learning. Org-wide release is a governance event. Treat it like one.
Document the consent grant date and the admin who approved it. When someone asks six months later why a bot can read a list, you want a paper trail, not folklore.
- Explain data sources in plain language.
- Request only the permissions the first version needs.
- Name an owner for secret rotation.
- Agree on a disable switch if the bot misbehaves.
Design the FAQ bot around a SharePoint list
Skip the echo bot. Build something boring and useful.
Create a SharePoint list with columns like Question, Answer, Keywords, Audience, LastReviewed, and Owner. Keep answers short enough to read in a mobile Teams window. Link out to the full policy page when needed.
The bot’s job: take a user utterance, match it against keywords or a simple search over the list, return the best answer card, and offer a button for “this was not helpful” that notifies a human owner.
Matching can start simple. Keyword contains. Later you can add smarter retrieval. Do not begin with a complex model if a filtered list query solves eighty percent of questions.
Concrete example. A facilities team got the same five questions every week about badge access, visitor Wi-Fi, and after-hours HVAC. We put those five plus twenty less common items into a list. The bot greeted users in a team channel and in personal scope. In the first month it answered most Wi-Fi questions without a human. The “not helpful” button caught two outdated answers, which we fixed in SharePoint without redeploying code. That separation is the point. Content lives in the list. Code stays thin.
Write answers like a helpful colleague, not like a policy PDF dumped into chat. One tight paragraph. One link. One owner name for disputes.
Conversation shape that does not annoy people
Greet briefly. Ask what they need in one sentence. If confidence is low, show two or three candidate questions as buttons instead of guessing wrong.
Never pretend certainty you do not have. “I am not sure. Here are close matches, or I can notify the facilities owner” builds more trust than a wrong badge policy delivered confidently.
Log questions that miss. That miss log is your product backlog. After two weeks you will see clusters. Add rows to the list. Resist the urge to hard-code special cases into the bot.
Keep personal data out of the list answers. The bot is for reusable knowledge. Employee-specific cases stay with humans.
Also decide channel versus personal chat behavior. In a busy channel, the bot should respond in a thread and keep quiet unless mentioned, if that fits your design. In personal chat, it can be more conversational. Noise policies matter as much as NLP quality.
Build order I recommend for a first version
First, get the SharePoint list reviewed by the real owners of the answers. Wrong content with a pretty bot is still wrong.
Second, scaffold with Teams Toolkit, connect the bot to a shared debugging team, and implement list lookup for a single known question end to end.
Third, add candidate buttons and the not-helpful path.
Fourth, write the admin consent brief and request packaging into the org catalog for a pilot group.
Fifth, watch the miss log for two weeks before adding fancy language features.
Testing should include people who were not in the design meetings. They phrase questions strangely. That is the real corpus.
When something fails, disable or unpin quickly. A stuck bot that replies with errors every minute will get your app blocked. Build a health check and a human-readable status.
- Content list first.
- Thin bot second.
- Pilot permissions third.
- Miss-log iteration forever.
What not to do on version one
Do not scrape random intranet pages without owners. Do not grant broad Graph permissions “for later.” Do not hard-code secrets in the repo. Do not skip admin conversations. Do not ship an echo bot and call it a pilot win.
Do not promise that the bot will replace a help desk. Promise that it will deflect the repetitive questions and route the rest with context. That promise you can keep.
Security basics stay ordinary and important: HTTPS, secret storage in a vault or pipeline variables, least privilege, audit of who changed list answers, and a named human on call for the first weeks.
If a flow already answers the need with a scheduled digest or a form submission path, keep the flow. Bots are for conversational entry points. Choose the smaller tool that fits.
Your first Microsoft Teams bot should feel almost dull. A SharePoint list. Clear consent. A mentionable helper that answers real FAQs and admits when it cannot. That dull bot earns the right to grow. The echo bot only earns a screenshot.