Updates for Microsoft Teams bots in Multi-Geo environments

Ojasvi Choudhary

This past July, we announced that Microsoft Teams is now included in Microsoft 365 Multi-Geo. With Microsoft 365 Multi-Geo, organizations have greater control over the location of specific data centers their data is stored in. Admins can provision and store data at rest in the geo locations of their choice to help meet data residency requirements, especially helpful for multi-national organizations. With this inclusion, we wanted to share some important updates that you should be aware of if you develop Teams bots.

Impact for bot developers

With this update, the service URL for a tenant might change and so users in the same tenant might have different service URLs. In this situation, our guidance remains the: please use the service URL from the incoming activity to reply. If the tenant or user URL changes, then both the old and new service URL will work.

For example, when your bot creates a 1:1 chat and sends proactive messages to all users within a group chat (team) – the serviceURL associated with that group chat (team) will work for contacting users 1:1. Your bot might receive a different serviceURL from the newly created 1:1 chat depending on the user’s preferred region. In this case you should use the serviceURL from the incoming activity (1:1 chat), however using the original serviceURL (group chat/team) will continue to work.

As a reminder, with Microsoft Teams Bots, the Bot Framework Connector service enables your bot to exchange messages with Teams users. The service uses industry-standard REST and JSON over HTTPS.

When a user sends a message to your bot, the incoming request contains an Activity object with a serviceUrl property that specifies the endpoint to which your bot should send its response. To access the Bot Connector service, use the serviceUrl value as the base URI for API requests.

For example, assume that your bot receives the following activity when the user sends a message to the bot.

{
    "type": "message",
    "id": "bf3cc9a2f5de...",
    "timestamp": "2016-10-19T20:17:52.2891902Z",
    "serviceUrl": "https://smba.trafficmanager.net/amer",
    "channelId": "channel's name/id",
    "from": {
        "id": "1234abcd",
        "name": "user's name"
    },
    "conversation": {
        "id": "abcd1234",
        "name": "conversation's name"
    },
    "recipient": {
        "id": "12345678",
        "name": "bot's name"
    },
    "text": "Haircut on Saturday"
}

The serviceUrl property within the user’s message indicates that the bot should send its response to the endpoint https://smba.trafficmanager.net/amer; this will be the base URI for any subsequent requests that the bot issues in the context of this conversation. If your bot will need to send a proactive message to the user, be sure to save the value of serviceUrl.

The following example shows the request that the bot issues to respond to the user’s message.

POST https://smba.trafficmanager.net/apis/v3/conversations/abcd1234/activities/bf3cc9a2f5de...
Authorization: Bearer eyJhbGciOiJIUzI1Ni...
Content-Type: application/json

Reach out for help

We’re here to help answer any questions or feedback you may have. For more information or where to go for help, please visit our developer engagement channels.

Happy coding!

Feedback usabilla icon