Microsoft Teams connection
The saved link to an Azure Bot backed by an Entra (Azure AD) application, which posts to Teams channels as a bot. In the connection picker it is Microsoft Teams. It is bot-only—there is no webhook option.
Powers these nodes
It is also what posts a paused AI step's question into a channel as an interactive card, and what carries the answer back.
Fields
| Field | Required | Description |
|---|---|---|
| Name | Yes | A name for the connection. |
| Auth → Tenant ID | Yes | The Entra directory (tenant) id. |
| Auth → Client ID | Yes | The Entra application (client) id. This is also the bot id. |
| Auth → Client Secret | Yes | The Entra client secret. Stored encrypted and never logged. Entra caps secret lifetime at 24 months—rotate before expiry. |
| Allowed Teams | No | The teams this connection may target. Leave it empty to allow any team in the tenant; when set, the action's team picker is limited to these teams. Populating it needs the Graph consent below. |
| Service URL | No | On the Advanced tab. The Bot Connector URL messages are sent through. Leave it blank for the global Teams cloud. |
| Inbound Issuer | No | On the Advanced tab. The issuer inbound Teams replies must be signed by. Leave it blank for the documented default. |
| Inbound JWKS URL | No | On the Advanced tab. Where Microsoft's signing keys are fetched from to verify inbound replies. Leave it blank for the documented default. |
The three Advanced fields exist for one case: a bot registered in a sovereign or government Microsoft cloud, which uses different endpoints from the public one. Leave all three blank otherwise—each connection resolves its own, so connections in different clouds can coexist. Changing the inbound two incorrectly stops Teams replies from being accepted while outbound posting keeps working.
Setting up the Microsoft Teams connection
Unlike Slack, this is a credential connection: you enter the app's identity directly rather than clicking Connect. The connection is usable once the three credentials are saved, but the team and channel pickers stay empty until an administrator grants admin consent.
Register the Entra app and Azure Bot
In the Azure portal, register an application under Microsoft Entra ID → App registrations and create an Azure Bot resource for it. Note three values: the Directory (tenant) ID, the Application (client) ID (this is also the bot id), and a client secret you generate under Certificates & secrets. Treat the secret like a password.
Enter the credentials
Open the Microsoft Teams connection on the Connections page and fill in Tenant ID, Client ID, and Client Secret. Save. The form shows a setup checklist with the exact permission names and the links used in the next steps.
Grant admin consent for the Graph scopes
The team and channel pickers read team and channel names from Microsoft Graph using the app's own identity, which requires admin consent for two least-privilege application permissions:
Team.ReadBasic.All—lists teams, so you can pick a team.Channel.ReadBasic.All—lists a team's channels, so you can pick a channel.
Neither grants write access or the ability to read messages. A Microsoft admin grants consent once—either with the "Grant admin consent for {tenant}" button on the app's API permissions blade in the Azure portal, or with the Grant admin consent link on the connection form. Both trigger the same tenant admin-consent flow, so use whichever is handier. Until consent is granted by either route, the pickers render empty with a readiness note; once it is, they populate automatically.
Download and install the app package
Once the connection is saved with a client id, the form offers a Download Teams app package button. Download it and, in Teams, upload it into each team you want to post to (Apps → Manage your apps → Upload an app). The bot must be installed in a team before it can post there—admin consent alone is not enough.
The package is interactive: the same app both posts messages and receives replies, which is what lets a person answer a human-in-the-loop request from inside a Teams card. Nothing extra is needed to enable that at the app level—but Teams can only deliver the reply if you also complete Enable approvals in Teams below.
(Optional) Curate the allowed teams
Leave Allowed Teams empty to allow any team in the tenant, or pick a subset to limit which teams the Teams Message action can target. When a subset is set, the action's team picker draws only from it—and does so offline, with no further Graph call.
Rotate the client secret
Entra caps client-secret lifetime at 24 months. The connection form carries a reminder to rotate the secret before it expires; a lapsed secret surfaces at send time as an authentication error.
Enable approvals in Teams
Posting to Teams works with the steps above. Answering a human-in-the-loop request from a Teams card needs one more piece: Microsoft has to be able to reach Esca Automations.
In the Azure portal, open your Azure Bot and set its Messaging endpoint to the platform's Teams interaction path:
1https://YOUR-ESCA-HOST/automation/teams/interact
Three things to know about that URL:
- It must be reachable from the public internet. Microsoft delivers each reply from its own servers, not from the person's browser, so a deployment on an internal network cannot receive them. This is a genuine requirement of the Teams bot platform rather than a restriction of the automation server.
- It must be
https://with a valid certificate. Azure will not accept a plain-HTTP messaging endpoint. - Leave it unauthenticated. Do not put basic auth or an IP allowlist in front of that path. Every request Microsoft sends is cryptographically signed, and that signature is verified before anything in the request is trusted—so the signature is the authentication. Another layer in front simply blocks delivery.
If the messaging endpoint is missing or unreachable, cards still post and still show their Submit button, but tapping it has no effect. The pause is not lost: the request stays answerable from the approvals inbox, so the automation can always be completed.
Your firewall also needs to allow outbound access to Microsoft's signing-key endpoint, alongside the Microsoft hosts the connection already reaches. Your administrator can find the current list in the internal Teams documentation.
Answering questions in Teams
Choosing Microsoft Teams as a provider on an AI step asks for three things:
| Field | Required | Description |
|---|---|---|
| Connection | Yes | The Microsoft Teams connection to post through. |
| Team | Yes | The team containing the target channel. Drawn from Allowed Teams when a subset is set, otherwise from every team in the tenant. |
| Channel | Yes | The channel where the question is posted. Populated from the selected team's standard channels. |
Recipient selection is picker-only here too—display names, never a raw id.
What the card looks like
The card opens with the automation's name and a one-line note that an automation has paused and needs input, followed by links to the automation and to the step that is waiting—so whoever receives it can see what asked, and go look.
Below that is the agent's question. The card's inputs are generated from the shape of that question, so a yes/no confirmation, a choice among options, and a multi-field form each render appropriately. A field the card cannot represent faithfully falls back to a text box rather than being dropped.
Last is a collapsible Details section holding the agent's most recent response—the summary it wrote just before pausing to ask. Click the row to expand it. Formatting in that summary, including lists, is preserved, and a very long response is clipped.
The agent's individual tool calls are not shown. The response is what explains the question, and tool arguments can contain content that does not belong in a channel.
When anyone answers—in Teams, in another channel, or from the approvals inbox—the card is replaced by a resolved version showing the answer and who gave it, so a stale card never keeps inviting a second submission.
Three behaviours worth knowing
- Progress is not streamed. Unlike Slack, the card appears when the agent asks its question rather than updating live as the agent works. Teams has no streaming primitive for cards, and repeatedly rewriting one runs into platform rate limits. The Details section is a snapshot taken at the moment the agent paused, not a live feed.
- The links depend on a configured default tool URL. Without one, the automation and step are still named on the card but are not clickable.
- In a dry run, the card is posted to the channel from the automation's Teams test override when one is configured. With no override the post is skipped entirely and the request is answered from the approvals inbox—so a dry run never messages a real channel by accident.