How to use Microsoft Teams for chatops

Encouraging collaboration is increasingly important in enterprises, with applications like Slack and Stride (Atlassian’s replacement for its own HipChat) getting ground-up adoption. Microsoft has its own Teams collaboration tool shipping as part of Office 365 Enterprise. (Microsoft also plans on folding Skype for Business conferencing client into Teams.)

Since its formal release about a year ago, Teams has added more integration features and a command line-like approach to application control. That encourages a move to self-service devops procedures using Teams as a host of what’s become known as chatops. It’s a model that uses platform integration to bring apps directly into team conversations, via bots and other chat-based tools. That is, you can talk directly with apps, one-to-one or as part of a team conversation.

Instead of triggering a build, for example, in an IDE or a continuous-integration server, a development team can review test results in a Teams room. The resulting collective go/no-go decision becomes a visible action, launching a build and a deployment, with results appearing in the chat so team members see what otherwise would be an opaque process.

For the chatops approach to work, apps need to be able to publish content directly into team conversations, so users won’t need to switch among apps. As a result, the information you need is in the same thread as your team discussion, making it easier to share important information and to make appropriate decisions.

Introducing Teams messaging extensions

Microsoft calls these interactions messaging extensions. They are cloud-hosted services that link existing applications, whether on-premises or in the public cloud, with Teams via existing channels. Originally developed for use with chatbots, they’re built on top of the existing Microsoft Bot Framework using its card UI metaphor. Originally called compose extensions, messaging extensions have been in beta for the last few months. Teams users will already be familiar with how to use them, because the tools used to build them also deliver Teams’s emoji and GIF support.

You start by registering a bot, which gives you the ID and endpoints needed to link your code to Teams. You also need to create an app manifest for your bot that adds support for compose extensions.

You can scope messaging extensions to individuals or a team, using commandIDs to handle routing queries to the appropriate code, generating cards in response that then display in a Teams chat for individual applications or in a team room for team-level applications.

Currently, there’s support for only one command in a messaging extension, though you can use parameters to refine the output. For example, the messaging extension offered by the Wrike project management service searches for work items, displaying the item you select as a card.

Building your first messaging extension

Once you’ve declared a composeExtension (Microsoft uses the old name here for compatibility with apps developed during the beta) in your bot’s JSON manifest, you construct a command object to handle interactions. This contains the text that describes your action, along with any parameters sent to and from Teams. A declarative approach like this makes a lot of sense, because you’re constructing a conversation between an application and Teams, one that’s structured through a RESTful API.

Like most interactive bot-based applications, messaging extensions are event-driven. You use the onQuery event to work with users in Teams, responding to messages. Microsoft provides sample C# and Node.js code for working with messaging extensions, though if you’re already building bots you shouldn’t find it hard to add messaging extension support to your existing code.

One thing to note, there’s a five-second response window for response from the remote service, with results to be sent in a JSON object that’s parsed by Teams and displayed in a card.

Probably the biggest difference between building an app that works with Teams and most other development models is that Teams provides minimal control over the user interface. Instead, you’re constrained to delivering a response that must fit inside one of Teams’ card types. Of course, there’s always of the option of responding with a link to a webpage or into a UWP application, though that doesn’t really fit into the idea that messaging extensions don’t break user flow.

Making messages into actions

One useful feature is the option of using an Office 365 Connector Card, for example, to assign a task to a user or to add an item to a calendar. By including actions in a messaging extension response, you’re building work elements into an ongoing conversation or into a meeting. Because requests include ID data, it’s easy to attach actions to an authenticated user.

Other card options let you deliver links that take a user to additional information, so a work item card might include a link to a project plan or to a Kanban board. That link might be to a tab in Teams or to an external application. However, there should be enough information in the card to let decisions be made without leaving Teams, leaving links as a way of getting extra information outside a chat or a team meeting.

Applications offering messaging extensions are listed in the Office Store, via a filtered view in the Teams app itself. Once such an application is installed, you call a messaging extension from the More Options button on the message compose box.

Another new feature in Teams replicates Slack’s familiar slash commands (themselves a derivative of the command model used by that old favorite, IRC). Applications using this feature trigger from shortcuts typed directly into Teams’ new command box, to quickly launch actions both inside and outside Teams. For example, you could set a status or switch between tabs and pages. Microsoft hasn’t yet detailed how apps can add their own slash commands, but it isn’t hard to guess that it’s likely to be via the Bot Framework as well.