使用 Microsoft Teams 活动源通知的最佳做法

本文介绍在 Microsoft Graph 中使用 Microsoft Teams 活动源通知的最佳做法。 这些最佳做法适用于：

• 创建行动号召通知
• 请求对通知的响应
• 创建有关外部事件的通知

下图显示了 Teams 中的活动源通知示例：

实现活动源通知时，请记住以下几点：

• Toast 通知会将用户重定向到活动源，而不是应用。 若要查看其他活动，用户必须在活动源中选择关联的通知。
• 用户只能在所选应用发送通知后管理通知设置。
• 应用清单中包含每个通知的图标。 Microsoft Graph 不支持自定义图标。
• 不支持优先级通知。

增强通知体验

Microsoft Teams 以活动源和 Toast 格式显示通知。 用户跨聊天、频道、会议或其他应用接收来自多个源的通知。 若要增强用户体验，请应用以下建议：

• 本地化通知 Toast 或源中的内容。 仅当应用的内容已本地化时，才会 进行本地化。
• 为 活动类型提供适当的标题和说明。 使用简短标题，例如 @提及 和公告。 避免使用长标题，例如 “用户提及的活动 ”和 “创建后”活动。
• 通知应传达与用户相关的重要信息。 例如， Diego 分配给你的销售票证 是相关消息; 乔尼离开的销售团队 不是。
• 避免发送本质上是促销性的通知，例如 在“自行车”应用中试用新功能。
• 避免机器人消息和活动源通知中的重复通知。 有关详细信息，请参阅 选择活动源通知或机器人框架消息。
• 在通知中使用 文本预览 部分。 根据需要提供信息以帮助用户确定通知的重要性并采取措施。
• 不要在通知标题的末尾添加句点，以便与 Teams 中的所有其他通知设置保持一致。
• 让用户清楚地了解通知与其内容之间的关系。 例如，当用户收到批准休假的通知时，通知应将他们重定向到应用的相应部分。 如果通知涉及删除或删除实体（如用户和任务），请将收件人定向到内容并指示所需的操作。
• 确保源体验是自包含的。 例如，任何弹出窗口和模式都必须保留在应用中。
• 验证你的应用每分钟发送的通知数不超过 20 个，每个用户。 如果计数超过 20，则通知将自动受到限制。
• 确保应用的加载时间不会对用户在源中的通知之间切换时的体验产生负面影响。
• 通知用户活动源中的通知存储周期。 在 Microsoft Teams 中，存储期为 30 天。

  注意

  30 天的存储限制适用于所有通知。 它不特定于通过活动源通知 API 发送的通知。

选择活动源通知或机器人框架消息

可以使用活动源通知或机器人框架消息，但不要同时使用这两种通知类型。 以下部分介绍通知类型以及何时使用每种通知类型。

活动源通知

活动源通知显示在 Teams 活动源中，可以包含指向不同位置的链接。 这些通知：

• 允许用户执行操作或对通知进行会审。
• 引导用户访问聊天或频道、个人应用或聊天或频道消息中的选项卡。

活动源通知 API 允许用户从通知设置中为每个 通知类型 配置通知。

如果使用活动源通知，请注意，如果应用向聊天或频道以及活动源发送机器人通知，则可能会发送双重通知。 仅当你的方案需要时，才发送双重通知。

使用委托通知创建更好的通知体验。 活动源通知 API 可以发送委托的或仅限应用程序的调用。 在委派呼叫中，通知的发送方显示为发起通知的用户，在仅限应用程序的调用中，发送方显示为应用。

可以更新现有活动源通知，而不是使用 chainId 参数创建新通知。

机器人框架消息

机器人消息以聊天或频道消息的形式传递。 如果用户打开聊天或频道通知，则触发的通知将作为聊天或频道消息发送。 若要发送机器人消息，请 @提及通知显示在活动源中的用户名。

它可用于将警报用作聊天或频道消息;例如，由所有通道成员使用的消息。

相关内容

• 为 Microsoft Teams 设计活动源通知
• Microsoft Teams API 概述