Bots & Custom Apps
Custom Microsoft Teams apps: when to build one
Custom Microsoft Teams apps are seductive. Someone sees a polished demo, opens a blank repo, and six weeks later the company owns a half-finished tab that only one developer understands. I have inherited those tabs. They sigh when you open the manifest.
I am Priya Shah. I help organizations automate work in Microsoft Teams. This essay is independent education, not partner marketing, and it is not endorsed by Microsoft. Use the checklist below to decide when a custom app is justified and when you should stay with flows, first-party apps, or a simple Adaptive Card.
A blunt checklist before anyone writes code
Ask the questions in order. Stop at the first yes that already solves the need.
Can a Power Automate flow plus a first-party app finish the job with acceptable user experience? If yes, do that.
Can an Adaptive Card posted by a flow or bot collect the decision or display the status without a custom tab? If yes, do that.
Do you need a custom Teams app because you require a tailored UI, a multi-step workspace inside Teams, Graph scenarios beyond what connectors offer cleanly, or a branded employee experience that cards cannot carry? Only then open the project charter.
Also ask who will maintain builds, secrets, and store submission updates after the original developer changes roles. If that answer is silence, you do not have a project. You have a future outage.
I keep this checklist on a single page. Sponsors initial it. That small ritual prevents vanity builds better than any architecture review theater.
- Flow enough?
- Card enough?
- Custom app truly needed?
- Named maintainers for twelve months?
- Admin and security path agreed?
When a flow is enough
Flows win for event-driven automation, approvals, notifications, and light data movement across Microsoft 365. If the user experience is “something happens, then Teams tells the right people, then someone clicks approve or opens a List,” stay with Workflows.
Flows also win when business users must adjust logic without a deploy pipeline. Changing a condition in Power Automate is often safer than shipping a new tab build for a wording tweak.
Limits exist. Complex interactive UIs, offline-ish experiences, or specialized rendering can outgrow flows. Reluctance to learn Power Automate is not the same as a technical limit. I push back when the only argument for custom code is taste.
A useful diagnostic: write the user story without mentioning Teams apps. If the story is mostly “when X, do Y, tell Z,” you are in flow land.
When an Adaptive Card is enough
Cards are underrated product surfaces. A status card with owner, state, and a submit action can replace a mini app for triage, acknowledgements, and lightweight intake.
Choose a card when the interaction is short, the data fields are few, and you do not need navigation between many screens. Choose a card when you want the work to stay in the chat rhythm instead of sending people to a separate tab they will forget.
Cards struggle when users need dense tables, advanced filtering, rich editing, or long forms. They also need careful versioning. Shipping card JSON from three different flows without a shared template becomes a visual mess.
If your prototype is a card and nobody asks for more screens after two weeks of real use, you have your answer. Do not “upgrade” to a custom app out of boredom.
Three cases where building a custom app is justified
First, a role-specific workspace that must live in Teams and combine data from several systems with interactive views connectors cannot express. Example: a field operations console that shows today’s routes, exception queues, and a controlled action panel tied to your operations API. Cards would drown. A List would be too flat. A custom tab can earn its keep.
Second, a guided multi-step process with branching UI, validation, and audit requirements that exceed Approvals and Forms. Think safety inspections with photo evidence rules, conditional sections, and a signed completion state written back to your system of record. You may still use Teams for distribution and auth, but the experience is an app.
Third, an organization-wide employee capability that needs consistent branding, lifecycle management, and centralized telemetry across many teams, where sideloaded scripts and one-off flows would create chaos. Internal app store distribution, versioning, and a product owner make sense here.
Concrete example from my notes. A manufacturing client wanted supervisors to clear line-down events from Teams. The first attempt was a flow posting a card. It worked until they needed live machine state, parts availability from an internal API, and a two-person confirmation rule with custom UI states. We built a narrow custom app for that scenario only. We did not rebuild their entire intranet as Teams tabs. Scope discipline made the build succeed.
Three cases where building is not justified
First, replacing Planner or Lists because someone dislikes the default look. Visual preference is not an architectural requirement. Theme frustration ages poorly as a business case.
Second, a notification center that only redisplays information already available in email digests and channel posts. If the custom app is a mirror with extra clicks, skip it.
Third, a project that exists because a vendor demo looked modern and the sponsor wants something to announce in a town hall. Announcement-driven software becomes orphaned software. I have retired more town-hall apps than I have extended.
Another near-miss pattern: building a custom app to avoid learning SharePoint permissions. You will still meet permissions, only with more code around them.
If a first-party app is blocked by policy, the answer is an exception request or a redesign, not a shadow app that duplicates the blocked capability with weaker security review.
Maintenance and governance you must budget
Custom Teams apps need manifests, certificates or secrets, Graph permission reviews, store or catalog updates, and compatibility checks when Teams clients change. Budget people hours, not only build sprints.
Name a product owner, a technical owner, and a backup. Put the app in source control. Define how configuration differs across dev and prod. Decide how you disable the app if it misbehaves.
Governance should include data classification, logging, retention, and whether personal chats or only team scopes are allowed. Admins will ask. Bring answers in the first meeting.
Measure adoption with real tasks completed, not install counts. An app installed company-wide and opened by twelve people is a costume.
- Owners and backups documented.
- Secret rotation scheduled.
- Support channel or queue named.
- Rollback plan tested once.
- Quarterly permission review.
I refuse to start builds without the maintenance line in the budget. It feels awkward in the kickoff. It feels prophetic a year later.
A decision meeting that stays honest
Bring the checklist, one flow prototype or card prototype if possible, and an estimate for twelve months of ownership cost. Ask the sponsor which outcome they will abandon if the custom app slips.
If they cannot name a process metric, delay the build. If they can, and flow or card prototypes fail those metrics in a pilot, proceed with a narrow custom scope.
Write down what the app will not do. Anti-scope prevents the tab from becoming a second intranet.
Custom Microsoft Teams apps are justified when interaction, integration depth, and organizational scale exceed flows and cards, and when named humans will own the aftermath. They are not justified as decoration, as a workaround for learning first-party tools, or as a souvenir from a keynote. Choose deliberately. Your future self is already busy enough.
I close most decision meetings with a calendar invite for a ninety-day review. In that review we look at usage, failure tickets, and whether a first-party feature released since launch made part of the custom code unnecessary. Retiring a slice of a custom app is a success, not a defeat. The goal was never to maximize code. The goal was to make a Teams-centered process reliable for the people who live in it.
If you are early in your automation practice, bias toward flows and cards for a full quarter. You will learn your tenant’s permission quirks, your admins’ review tempo, and your users’ patience for new UI. Those lessons make a later custom app cheaper and kinder. Jumping straight to a custom build teaches expensive lessons in public.
Write the decision down either way. “We will not build; we will use Approvals plus a List through September” is a complete architecture choice. So is “We will build a narrow supervisor tab for line-down events, owned by Ops Engineering, reviewed every ninety days.” Ambiguous middle ground is where orphaned tabs are born. Pick a lane, fund the maintenance, and revisit with evidence instead of vibes.