Microsoft Teams: Options for Building Apps

Organizations that run Microsoft Teams collaboration solution should consider developing custom apps to boost their end users’ productivity. However, creating these apps will only make sense, and gain user adoption, when they enhance or extend collaborative processes.

Microsoft Teams has five mechanisms for building apps:

With the tab-based model, companies should focus on enabling collaborative processes around content or providing informational resources for users of a space. Tabs essentially provide a way to view and navigate information that resides elsewhere in the organization, rendering that information in an .

For example, a deal desk could have a tab-based application that contains links to information about products and services, contract language, regulatory requirements, pricing, and other supporting information necessary to gain approvals and correctly structure contracts for complex sales opportunities. Not only does it make it easier for teams to find the information they need to develop a contract, it also makes it easy to share that information with other team members so they understand why a deal can, or cannot, support certain pricing or services provisions. 

Messaging extensions give developers a way to build task-oriented functionality, accessible through the Teams client user interface, to send and receive information via a web service. The Microsoft Teams client supports using messaging extensions in the command/search box at the top of the client, the actions element of a message or the new message form.

In practice, messaging extensions allows organizations to build simple interactions with external systems. For example, a user could use a form to reserve a resource such as a piece of equipment. That system would then respond back, via a Teams card, confirming the reservation. Another example would be submitting a conversation to initiate or close out a help desk request.

When building a messaging extension, building it as a bot within Microsoft’s Bot Framework SDK will simplify development as the Bot Framework includes a messaging schema and secure communications protocol.

Bots use web services to integrate with other applications to send and receive data, but they can also function as chatbots to drive conversational interactions with end users. While they can drive simple interactions, they can use natural-language-processing and artificial intelligence for more complex interactions as well.

While the Bot Framework SDK allows developers to build bots using C#, Python, JavaScript and Java, companies also can build bots using Microsoft’s no-code Power Platform via Power Virtual Agents. Developing bots can be challenging, so it may be worthwhile to use the Power Virtual Agent to try out some concepts and gauge user acceptance.

Webhooks and connectors give developers a simple mechanism to connect web services to channels and teams within the Teams application. They have some basic limitations, however, so an organization will need to consider the end user types and channel context before implementing them. They only work within a specific channel or team.

Outgoing webhooks provide a mechanism for users of a channel to send a message to a service by @mention of the web service. This means that these @mentions have to be channel specific. In addition, the service only has five seconds to respond via a text or card response. This means that users have to be both aware of the use case of the @mention and understand what a lack of response means. This means organizations may only want to use this with more technically savvy users, such as with an operations team so they can check the status of an application, device or network-based service.

Incoming webhooks provide a way for a service to notify a team channel, so they will be team specific. This makes them best suited as an alerting mechanism for a channel to provide status updates from particular services. An infrastructure operations team may want to receive notifications, for example, when crossing utilization thresholds.

Finally, the Microsoft Graph API has a permissions model, called RSC (resource-specific content), that provides a way for developers to integrate Teams and the Graph API for application management. Currently in preview and part of the Microsoft Graph API beta, RSC provides a way for team owners to grant consent for an application to access and modify team data. RSC is designed to provide granular, Teams-specific permissions for applications.

For example, the RSC can control permissions for updating channel names, descriptions and settings for a given team. It can control permissions for creating, updating or deleting a team’s tabs. Companies that want to build applications for Microsoft Teams should be exploring the RSC permissions model, the management requirements, how it functions and set up requirements within Azure Active Directory portal.