Microsoft Graph 

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction of this topic with the link here. The previous article discussed the Microsoft Graph Data Connect used with Microsoft Graph. This article discusses the best practices for using Microsoft Teams activity feed notifications. Microsoft Graph enables integration with the best of Microsoft 365, Windows 10 and Enterprise mobility and security services in Microsoft 365, using REST APIs and client libraries

Microsoft Graph provides a unified programmability model by consolidating multiple APIs into one. As Microsoft’s cloud services have evolved, the APIs to reference them has also changed. Originally, when cloud services like Exchange Online, Sharepoint, OneDrive and others evolved, the API to access those services was launched too. The list for SDKs and REST APIs for these services started growing for developers to access content. Each endpoint also required Access Tokens and returned status code that were unique to each individual service. Microsoft Graph brought a consistent simplified way to interact with these services.

This article covers the best practices for using Microsoft Teams activity feed notifications in Microsoft Graph which apply to:

-          Creating call-to-action notifications

-          Requesting responses to notifications

-          Creating notifications about external events

Microsoft Teams displays notifications in both activity feed and toast formats. Users can receive notifications from multiple sources across chats, channels, meetings, or other applications.  It is recommended that the content be localized in a notification feed or toast and the application must also be localized for this purpose. Appropriate titles and descriptions must be provided for the notified activity types. Short tiles such as @mention or Announcements are preferable. Notifications should be filtered to show only what is relevant to the user. Promotional notifications must be avoided. Notifications from messages and those coming from activity feed notifications can be redundant. Those duplicates must be removed. The text preview section in notifications can be used so that the user can take the necessary action.  A period at the end of the notification title is not required and this will be consistent with those that Teams generates. The relationship between the notification and the content must be clear to the user. The feed experience should be self-contained. The application does not send more than ten notifications per minute, per user. The load time of the application does not negatively affect the experience for the users. The user must be informed about the notification’s storage period.

The activity feed notifications or bot framework messages can be used but they should not be used together. The activity feed notifications must appear in the Teams activity feed for the convenience to the user to take actions. It can include links to other locations, but the user must be able to decipher the notification and follow the link to the source. The corresponding API allows the user to take notifications for each notification type. Delegated notifications create a better notification experience. These can be delegated or application-only calls. The sender of the notifications appears as the user who initiated the notification in delegated calls but appears as the application in the application-only calls.

The bot framework messages are delivered as the chat or channel messages and triggered by the keyword @mention the name of the user. This in-lining of an alert as a chat or channel message is required for the purpose of broadcasting to all channel members. These are some of the best practices to use with such notifications.