利用Teams Adaptive Cards构建动态审批与数据收集流程 #
引言：告别静态表单，拥抱智能交互 #
在当今快节奏的团队协作中，传统的审批与数据收集方式——如电子邮件、共享文档或独立的Web表单——正日益显露出其局限性。流程割裂、信息分散、状态不透明、操作繁琐等问题严重拖慢了团队效率。Microsoft Teams作为现代团队协作的核心枢纽，其强大的集成能力与扩展性为解决这一痛点提供了绝佳平台。而Adaptive Cards正是开启这扇大门的钥匙。它并非一个独立应用，而是一种开放的、跨平台的UI片段（卡片）定义标准，能够在Teams、Outlook、Windows等众多微软产品中，以一致、丰富且交互式的方式呈现信息。本文将带领您深入探索如何利用Adaptive Cards，在Teams环境中构建出灵活、动态、自动化的审批与数据收集流程，从而将团队协作从被动等待转变为主动推进，彻底释放生产力。
第一章：理解Adaptive Cards——动态流程的基石 #
1.1 什么是Adaptive Cards？ #
Adaptive Cards是一种基于JSON的开放式卡片交换格式，由微软发起并维护。其核心设计理念是“一次创作，随处体验”。开发者只需定义一次卡片的JSON结构，该卡片便可以自适应地渲染在支持它的各种平台和应用程序中，包括Microsoft Teams、Outlook、Windows通知、Cortana、Bot Framework等，并保持交互功能的一致性。
与Teams中传统的“连接器”消息或简单的文本格式相比，Adaptive Cards提供了以下革命性优势：
- 丰富的交互元素：支持文本框、下拉列表、日期选择器、单选按钮、复选框、按钮、图像集等，足以构建复杂的表单。
- 动态内容更新：卡片提交后，可以根据后端处理结果，原位刷新卡片内容（如显示“已批准”、“需修改”状态），无需发送新消息造成信息流混乱。
- 自适应布局：卡片容器会根据宿主应用（如Teams桌面端、移动端）的宽度自动调整内容布局，确保最佳显示效果。
- 开放标准：JSON格式易于生成和解析，与任何后端服务或编程语言都能轻松集成。
1.2 Adaptive Cards在Teams中的应用场景 #
在Teams的上下文中，Adaptive Cards主要通过以下方式送达用户：
- 通过机器人（Bot）发送：这是最常见和强大的方式。一个在Teams中注册的Bot，可以主动向用户、群聊或频道发送Adaptive Cards，并接收用户对卡片的交互（如提交表单）。
- 通过传入Webhook发送：虽然Teams的传入Webhook功能较为基础，但也可以通过其有限的功能发送简单的Adaptive Cards（通常无法实现复杂的交互和动态更新）。
- 在消息扩展（Messaging Extension）中返回：用户通过搜索命令触发消息扩展，可以返回一个Adaptive Card作为搜索结果或表单。
- 在标签页（Tab）中嵌入：作为Teams应用的一部分，Adaptive Cards可以嵌入到配置页或内容页中，提供静态或动态的UI。
对于构建审批与数据收集流程，“Bot + Adaptive Card”的组合是最为灵活和推荐的技术路径。Bot作为流程的交互代理，负责卡片的投递、接收响应以及与后端逻辑服务的通信。
第二章：规划动态审批与数据收集流程 #
在动手开发之前，清晰的流程规划至关重要。一个典型的动态流程包含以下几个核心环节：
2.1 流程阶段分解 #
- 触发（Trigger）：流程由某个事件启动。例如：员工在SharePoint列表提交采购申请、代码仓库中创建了合并请求（Pull Request）、服务台系统收到一个新工单，或每周五下午需要收集项目周报。
- 生成与投递卡片（Card Generation & Delivery）：流程后端（如Azure Logic App、Azure Function或自定义API）捕获到触发事件，根据预定义的模板生成包含所有必要字段的Adaptive Card JSON，并通过Teams Bot发送给指定的审批人或数据填写人。卡片可能被发送到：
- 个人的聊天（1对1聊天，与Bot）。
- 团队频道（@提及特定审批人）。
- 群组聊天。
- 交互与提交（Interaction & Submission）：审批人或填写人在Teams内直接与卡片交互，填写信息、做出选择（批准/拒绝/需修改）并点击提交按钮。
- 数据处理与路由（Data Processing & Routing）：Bot接收到提交的数据（一个JSON对象）。后端逻辑根据数据内容决定下一步操作：
- 审批流：如果被批准，则更新原始系统状态，并可能触发下一个环节（如通知财务）；如果被拒绝或需修改，则更新卡片状态并通知申请人，或直接向申请人发送一张包含审批意见的修改卡片。
- 数据收集流：将提交的数据写入数据库（如Azure SQL、Cosmos DB）、Excel Online或CRM系统，并可能自动发送确认卡片。
- 状态反馈与更新（Status Feedback & Update）：最关键的一步。原始卡片的内容应立即被更新，以反映当前状态（例如，按钮消失，代之以“✅ 已由张三批准”的文本），实现流程透明化。这通过Adaptive Cards的
Update活动实现。
2.2 设计高效的卡片表单 #
一个设计良好的表单卡片是流程成功的一半。请遵循以下原则：
- 信息分层：使用
Container和FactSet清晰展示只读的上下文信息（如申请单号、申请人、时间），使用Input.*控件收集动态数据。 - 控件选择恰当：对于固定选项使用
Input.ChoiceSet（下拉或单选），对于日期使用Input.Date，对于多行文本使用Input.Text并将isMultiline设为true。 - 验证与必填：在JSON中利用
Input.*的isRequired和regex属性进行前端基础验证。复杂验证应在后端进行。 - 行动引导明确：使用
Action.Submit按钮，并通过title和style（positive表示批准/确认，destructive表示拒绝/取消）清晰表达操作意图。
第三章：技术架构与工具选型 #
构建一个健壮的流程需要选择合适的工具链。以下是微软生态下的推荐组合：
3.1 核心组件 #
- Microsoft Teams Bot：流程的交互前端。需要在Azure Bot Service注册，或使用Bot Framework SDK自行托管。它负责与Teams通信。
- Adaptive Cards JSON模板：定义卡片UI和数据结构。可以使用Adaptive Cards Designer在线工具进行可视化设计和预览。
- 流程自动化引擎：强烈推荐使用Power Automate。它作为流程的“大脑”和“连接器”，优势巨大：
- 丰富的连接器：可轻松连接Teams（通过“向Teams用户发送自适应卡片”操作）、SharePoint、SQL、Office 365、Dynamics 365等数百种服务，处理触发和后续操作。
- 内置Bot服务集成：无需深度编码即可处理Bot的HTTP调用。
- 易于维护：图形化界面降低了开发和维护门槛。
- 数据存储：根据需求选择，如SharePoint列表、Dataverse、Azure SQL Database等。
- （可选）自定义API：对于极复杂的业务逻辑，可以使用Azure Functions或ASP.NET Core Web API作为补充。
3.2 推荐的架构模式 #
模式A：Power Automate为中心的低代码模式（适合大多数场景）
触发事件 (如 SharePoint新增项) -> Power Automate -> 生成Adaptive Card JSON -> 通过“发送自适应卡片”操作发给Teams用户 -> 用户提交 -> Power Automate接收HTTP请求 -> 解析数据、执行业务逻辑、更新数据源 -> 通过“更新自适应卡片”操作更新原卡片。
模式B：自定义Bot与后端服务模式（适合需要高度定制化Bot行为或复杂对话的场景）
触发事件 -> 调用自定义API/Azure Function -> API生成卡片并通过Bot Framework SDK发送 -> 用户提交 -> Bot SDK接收 `Activity` -> Bot将数据转发给后端逻辑服务 -> 后端处理并调用SDK更新卡片。
对于希望快速上手的团队，模式A是最高效的选择。接下来我们将以此模式为重点进行实战讲解。
第四章：实战演练 - 构建采购审批流程 #
让我们以最常见的“采购申请审批”为例，分步构建一个完整的动态流程。
4.1 步骤一：准备环境与创建Bot #
- 创建Power Automate流：登录Power Automate门户，创建“即时云端流”。
- 添加Teams连接器：在触发器中搜索并选择“当收到HTTP请求时”。稍后我们将配置Bot来调用此端点。
- 注册Bot（通过Azure Bot Service）：
- 进入Azure门户，创建“Azure Bot”资源。
- 选择“多租户”或“单租户”，Bot类型选择“多轮对话”。
- 记下
Microsoft App ID和Client Secret（需新建）。 - 在配置中，启用“Teams”频道。
- 连接Power Automate与Bot：我们需要一个桥梁。一种方法是使用Power Automate的“向Teams用户发送自适应卡片（预览）”操作，它内置了Bot能力。或者，使用HTTP操作手动调用Bot的API，但这更复杂。本例采用前者。
4.2 步骤二：设计Adaptive Card JSON #
使用Adaptive Cards Designer设计采购审批卡。以下是一个简化版的JSON示例，展示了核心结构：
{
"$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
"type": "AdaptiveCard",
"version": "1.5",
"body": [
{
"type": "TextBlock",
"size": "Medium",
"weight": "Bolder",
"text": "采购申请审批",
"wrap": true
},
{
"type": "FactSet",
"facts": [
{ "title": "申请单号:", "value": "${if(triggerBody()?['ID'], triggerBody()?['ID'], '未获取')}" },
{ "title": "申请人:", "value": "${triggerBody()?['Author']?['DisplayName']}" },
{ "title": "申请部门:", "value": "${triggerBody()?['Department']?['Value']}" },
{ "title": "申请时间:", "value": "${formatDateTime(triggerBody()?['Created'], 'yyyy-MM-dd HH:mm')}" }
]
},
{
"type": "TextBlock",
"text": "**物品详情**",
"weight": "Bolder",
"separator": true
},
{
"type": "TextBlock",
"text": "${triggerBody()?['Title']}",
"wrap": true
},
{
"type": "Input.Text",
"id": "approverComment",
"placeholder": "请输入审批意见（可选）",
"isMultiline": true,
"isVisible": false
},
{
"type": "TextBlock",
"text": "**当前状态：等待审批**",
"id": "statusText",
"color": "Accent",
"weight": "Bolder"
}
],
"actions": [
{
"type": "Action.Submit",
"title": "批准",
"data": {
"action": "approve",
"requestId": "${triggerBody()?['ID']}"
},
"style": "positive"
},
{
"type": "Action.Submit",
"title": "拒绝",
"data": {
"action": "reject",
"requestId": "${triggerBody()?['ID']}"
},
"style": "destructive"
},
{
"type": "Action.Submit",
"title": "需修改",
"data": {
"action": "requestChange",
"requestId": "${triggerBody()?['ID']}"
}
}
]
}
注意：上述JSON中的${...}是Power Automate的动态内容表达式，用于在生成卡片时注入从触发事件（如SharePoint）中获取的实际数据。
4.3 步骤三：在Power Automate中构建主流程 #
- 配置HTTP请求触发器：复制URL备用。可以根据需要生成JSON schema以增强类型安全。
- 添加“发送自适应卡片”操作：
- 操作：选择“向Teams用户发送自适应卡片（预览）”。
- 收件人：选择“电子邮件”，输入审批人的公司邮箱。
- 自适应卡片：选择“自定义”，将上一步设计的JSON粘贴进去。利用动态内容面板，将SharePoint触发器的字段（如
ID,Author DisplayName）映射到JSON的表达式中。 - 关键：在“更新消息”字段中，填写一个唯一标识符，例如
concat('PurchaseRequest-', triggerOutputs()?['body/ID'])。这是后续更新该卡片所必需的。
- 保存并测试流：手动运行此流，或模拟一个SharePoint新建项事件，检查审批人是否能在Teams中收到卡片。
4.4 步骤四：处理卡片提交与动态更新 #
用户点击“批准”、“拒绝”或“需修改”后，数据会发送到一个由Teams平台指定的端点。为了捕获它，我们需要另一个Power Automate流。
- 创建第二个流（处理响应流）：新建一个“即时云端流”。
- 设置触发器：选择“当收到HTTP请求时”。这是Teams平台将提交数据回调的地址。复制此HTTP POST URL。
- 配置Teams Bot的响应URL：回到第一个流（发送卡片的流），在“发送自适应卡片”操作中，找到“待更新卡片”相关的设置（或查找
msteams连接器中的“等待响应”模式）。更常见的模式是：在“发送自适应卡片”操作后，连接器的运行会暂停并等待响应，响应数据会自动出现在后续步骤中。确保你使用的连接器支持这种“等待响应”模式，这是实现动态更新的关键。 如果所用操作不支持，则需要一种替代方案：在发送卡片时，在卡的Action.Submit的data对象中，手动添加一个属性"responseUrl": "<第二个流的HTTP请求URL>"。这样，当用户提交时，Teams会将数据提交到这个自定义URL。 - 解析响应数据：在第二个流（处理流）的HTTP请求触发后，解析
triggerBody()。你会得到一个包含action,requestId,approverComment等字段的JSON对象。 - 执行业务逻辑：添加“条件”控制。
- 如果
action等于"approve"：- 在SharePoint中更新对应
requestId的申请单状态为“已批准”。 - 使用“更新自适应卡片”操作（需要消息ID和更新消息ID），将原卡片的内容替换为新的JSON。新JSON中，
body部分移除所有Input.*控件和按钮，将statusText的文本改为“✅ 已批准 [时间]”，并显示审批意见。actions数组可以为空。 - （可选）启动下一个流程，如通知财务人员。
- 在SharePoint中更新对应
- 如果
action等于"reject"或"requestChange"：- 更新SharePoint状态为“已拒绝”或“需修改”。
- 更新原卡片状态。
- 向申请人发送通知：可以创建一张新的Adaptive Card发送给申请人，告知审批结果和意见，甚至可以附上一张让申请人重新修改提交的卡片，形成一个闭环。这正是动态流程的精髓所在。您可以在我们的另一篇文章《利用Microsoft Teams API构建智能考勤与工时统计机器人》中，找到关于如何通过Bot与用户进行复杂交互的更多灵感。
- 如果
- 返回响应：HTTP请求操作通常需要返回一个200 OK响应，有时还需要返回一个包含更新后卡片JSON的响应，以便Teams进行即时更新。具体格式需参考Teams Bot Framework文档。
通过以上步骤，一个具备动态更新能力的审批流程就搭建完成了。审批人所有的操作都在Teams内完成，状态实时反馈，流程清晰可见。
第五章：高级技巧与最佳实践 #
5.1 实现多级串联审批 #
对于需要多人顺序审批的场景，关键在于状态管理和路由。
- 在数据源（如SharePoint列表）中设计状态字段：例如“状态” = 待部门经理审批 -> 待总监审批 -> 待财务审批 -> 完成。
- 在Power Automate中维护审批人映射表：根据申请部门、金额等条件，动态决定下一级审批人。
- 当前审批人批准后，流程逻辑判断是否进入下一级。如果是，则使用相同的“发送自适应卡片”操作，向下一级审批人发送一张新的卡片。同时，将上一张卡片更新为“已由[姓名]批准，转交下一级”的状态。
- 使用《Teams Power Platform深度整合：零代码自动化工作流构建》中介绍的技术，可以更优雅地管理这种多步骤、有条件分支的复杂逻辑流。
5.2 安全性考量 #
- 验证发送者：在处理卡片提交的HTTP请求触发器中，验证请求是否来自合法的Teams服务（例如，验证JWT令牌，或至少在Power Automate中使用触发器返回的URL，因其具有SAS令牌）。
- 最小权限原则：Power Automate流使用的连接器（如SharePoint、Teams）应使用具有最小必要权限的服务主体或账户。
- 数据不落地：卡片中避免包含高度敏感信息。对于敏感数据，卡片上只显示引用ID，审批人点击“查看详情”按钮后可调用一个安全API获取详细信息。
- 防范篡改：提交数据中的
requestId等标识符应在后端重新验证，确保用户只能操作其有权审批的条目。
5.3 性能与可维护性 #
- 卡片模板化：将复杂的Adaptive Card JSON存储在Azure Blob Storage或SharePoint文档库中作为模板，在Flow中读取并注入数据，便于统一更新UI。
- 错误处理与重试：在Power Automate中为关键步骤（如更新SharePoint、更新卡片）配置失败后的重试策略和错误通知（如发送邮件到管理员Teams频道）。
- 日志记录：在关键节点使用“撰写”操作或Azure Log Analytics记录流程执行日志，便于审计和故障排查。
第六章：超越审批——动态数据收集的创意应用 #
Adaptive Cards的动态能力同样为数据收集打开了新天地。
- 每日站会更新：Bot每天定时向敏捷团队每个成员发送一张卡片，收集“昨日完成”、“今日计划”和“阻塞问题”。提交后，数据自动汇总并发布到团队频道。
- 客户反馈收集：在与客户的会议结束后，自动发送一张评分和意见收集卡。数据直接进入CRM（如Dynamics 365）。
- IT服务台快速分类：用户通过@提及Bot发起求助，Bot回复一张包含常见问题分类和描述框的卡片，提交后自动在ServiceNow或Zendesk创建工单。
- 培训签到与测验：在培训会议进行中，讲师通过Bot发送签到卡片或随堂测验卡片，结果实时统计。 这些场景的核心模式与审批流类似：触发 -> 发送交互式卡片 -> 收集结构化数据 -> 处理并存储 -> 反馈。其优势在于将数据入口无缝嵌入工作流上下文，极大提升了提交率和数据质量。
常见问题解答 (FAQ) #
Q1: 使用Power Automate发送自适应卡片，需要额外付费吗？ A1: Power Automate本身按流运行次数或基于每个用户计划收费。“向Teams用户发送自适应卡片”操作可能需要特定的Power Automate许可证（通常包含在Microsoft 365 E3/E5等套件中）。具体许可要求请查阅微软官方最新文档。构建复杂的企业级流程时，考虑《Microsoft Teams 2025年终极选购指南：免费版 vs 付费版 vs 企业版核心差异》中提到的Teams高级版或Power Automate高级版功能可能更有必要。
Q2: Adaptive Cards可以上传文件吗？
A2: 原生Adaptive Cards标准目前（版本1.6）不直接支持文件上传控件。这是一个常见的需求缺口。变通方案是：在卡片上放置一个按钮，其Action.OpenUrl打开一个预填充了上下文的、支持文件上传的网页（如Power Apps应用或自定义页面）。用户在该页面上传文件后，网页后端再将文件与卡片提交的数据关联起来。
Q3: 卡片发送后，如何设置一个审批超时（例如24小时未处理则自动提醒或转交）？ A3: 这是实现健壮流程的关键。在Power Automate中，当发送卡片后，可以并行启动一个“延迟”分支（延迟24小时）。延迟结束后，检查SharePoint中该申请的状态字段。如果状态仍为“等待审批”，则执行后续操作，如：向原审批人发送提醒卡片、更新原卡片为“已超时”，或根据规则自动转交给备选审批人。
Q4: 能否在Teams移动端完美使用这些自适应卡片流程？ A4: 是的，Adaptive Cards的一大优势就是跨平台自适应渲染。在Teams iOS和Android应用上，卡片会根据移动端屏幕宽度自动调整布局，所有交互功能（输入、选择、提交）均正常工作。为确保最佳体验，在设计卡片时应避免过于复杂的、依赖宽屏的列布局，并测试移动端下的显示效果。
结语：开启智能化团队协作新篇章 #
利用Teams Adaptive Cards构建动态流程，绝非简单的技术替换，而是一次工作模式的升级。它将分散、被动、线下的流程，整合进团队每天高频使用的协作中心，使其变得集中、主动、透明且可追踪。通过本文介绍的低代码（Power Automate）路径，即使没有深厚开发背景的团队也能快速构建出强大的自动化流程。
从简单的请假审批到复杂的多部门数据收集，Adaptive Cards所提供的交互性与动态更新能力，为流程自动化赋予了“智能”与“灵动”的特性。结合微软生态中强大的Power Platform和Azure服务，您可以不断扩展流程的边界，打造真正以Teams为核心的数字化工作流。现在，就从一个具体的业务痛点开始，尝试用Adaptive Cards和自动化流程来破解它，您将亲身体会到团队效率与体验的显著提升。