Governed approvals in Microsoft Teams
Post decision cards for plans, patches, replies, and deployments into the channels your team already watches. Ticket questions get answered in place, intake is routed, and each decision is attributed to a linked identity.
What the Teams bot handles
Governed intake
An @mention in a channel becomes a work item in the bound FixControl project, scoped to your tenant. The item then follows the normal triage and approval flow.
Ticket questions
Ask the bot what’s open or waiting for approval across FixControl, Jira, and Freshdesk. A pre-intake intent gate separates questions from new work, so asking about a ticket doesn’t file another one.
Approvals on decision cards
Plans, patches, replies, and deployments arrive as decision cards. Approve or request changes on the card; the decision is recorded with actor, role, and channel.
Cards stay in sync
A decision made in Teams updates the card and the operational timeline together. The channel and the app show the same state.
Verified identities
Teams users link a FixControl identity before they can decide. Verified and elevated tiers let policy demand stronger identity for riskier approvals.
Channel-aware replies
The bot replies in the channel where the request came from. In shared or public channels it withholds internal ticket detail, following the tenant’s visibility rules.
Intake, posting, and identity each report their own health
A Teams connection is several paths, not one: receiving messages, answering, posting cards, and binding identities can each be healthy or broken on their own. FixControl probes them separately, so a failing outbound path is visible instead of hidden behind a connected badge.
The bot ingests messages and mentions routed to it and turns them into governed work items in the bound project, inside your own organization.
Answers questions about existing FixControl, Jira, and Freshdesk tickets, with a gate in front of intake so a question doesn’t create an issue.
Posts decision cards for plans, patches, replies, and deployment gates, and records each approve or request-changes decision with attribution.
Requires the bot to be installed in the team and reachable. Outbound posts are queued in the integration outbox instead of being fired directly at the Teams API.
The bot can run single-tenant, matching how your Azure app is registered. In that mode it obtains tokens from the tenant where the app is registered, rather than from the multi-tenant Microsoft endpoint.
Available once a Teams user links their FixControl identity. Governance policy can require the elevated tier for higher-risk decisions.
There isn’t one. Posting can fail while intake still works, so FixControl reports each capability separately.
Outbound Teams messages either land or get flagged
Teams-specific questions
Is Teams just a chatbot in FixControl?+
Does the Teams bot run single-tenant or multi-tenant?+
What happens if a Teams post fails?+
Who can approve from Teams?+
Are approvals from Teams audited?+
Can sensitive ticket detail leak into a shared channel?+
Put a decision card in a Teams channel
Book a demo, approve a change from Teams, and trace the decision in the ledger.