小村软件有限公司
联系我们
菜单

用 Power Automate 自动处理邮件收到的订单・发票 PDF ── 保存、分类、通知与读取的设计

· 更新日期: · · Power Automate, 云端流程, Outlook, SharePoint, AI Builder, 业务自动化, 邮件, Office, 技术咨询

「把订单邮件附带的 PDF 订单，每天早上保存到共享文件夹，再转录到 Excel 的接单台账里。」这项工作，负责人每天手动花费30分钟——这样的公司并不少见。实际上，在 Power Automate 的咨询中，「想把邮件收到的单据处理自动化」这类需求相当常见。

乍看之下是一个简单的自动化，但实际动手做起来，会发现这是一个坑点不少的领域。签名的图片也被保存下来，把文件夹弄得一团糟。流程在无关的邮件上运行，导致误保存。附件较大的邮件却莫名其妙没有被处理。本文将依次整理从接收触发器到保存、分类、通知的基本流程，实务中容易踩到的坑点，是否要深入到用 AI Builder 读取内容（自动化转录）的判断依据，以及「邮件附件」这种接收方式本身的局限性。

1. 先说结论

  • Office 365 Outlook 连接器的「收到新邮件时 (V3)」触发器提供了文件夹、发件人、主题过滤器、「仅限有附件」等筛选条件。这些条件应尽量在触发器一侧指定，而不是放到后段的条件分支动作中。12
  • 接口不要设在负责人个人的收件箱，而应设为共享邮箱（例如 order@自家域名）。有专用触发器「共享邮箱收到新邮件时 (V2)」，只要连接账户拥有该共享邮箱的访问权限即可使用。3
  • 仅凭「有附件」这一判断，会把签名、徽标等内联图片也当作附件收进来。基本的应对方法是用附件元数据中的 Is Inline 属性配合扩展名进行过滤。4
  • 保存目的地设为 SharePoint 文档库，用「创建文件」动作写入，再通过 Teams 或邮件通知保存完成，这种结构比较易于处理。5
  • 如果要深入到读取内容（自动化转录），会用到 AI Builder 的文档处理，但需要另行准备消费型的积分（容量），并且提取结果必须设计人工确认环节。由于许可证体系从2025年起正在发生变化，导入前需要确认最新信息。67
  • 对于以密码保护 ZIP（PPAP）形式送达的附件，与其试图在流程中解开它，不如从根本上改变接收方式，这才是本质性的对策。

2. 梳理业务对象 ── 「邮件附件收到的单据」能自动化到什么程度

首先来确认一下本文所针对的业务形态。

  • 交易对象通过邮件附件发来订单、发票、送货单等 PDF
  • 负责人打开它，保存到共享文件夹中固定的位置
  • 将内容（交易对象名称、金额、品目等）转录到 Excel 或业务系统中
  • 通知负责人及相关人员「收到订单了」

接单方式存在传真、邮件附件、Web 表单、EDI 等不同阶段。邮件附件比传真更容易数据化，但相较于 EDI、数字发票这类结构化的数据对接，仍处于中间位置。这一整体图景在另一篇文章「EDI 是什么？如何让企业间的接单变得轻松 ── 从传真、邮件、手动录入迈向数据对接」中有所整理。

在此基础上，如果把「仍维持邮件附件方式，通过自动化能实现的范围」进行划分，大致可分为以下三个阶段。

阶段 要做的事 效果 难度・成本
(1) 保存・分类・通知 将附件 PDF 自动保存到 SharePoint 的指定文件夹，并通过 Teams / 邮件通知 消除每天「打开・保存・通知」的作业。不再出现漏保存、保存错位置的情况 低。可以用标准连接器的组合来搭建
(2) 读取内容（自动化转录） 用 AI Builder 从 PDF 中提取交易对象名称、金额、品目等，写入清单或系统 减少转录作业。但提取精度并非100%，需要人工确认机制 中。需要 AI Builder 的容量（积分）以及异常处理设计
(3) 改变接收方式本身 迁移到 Web 接单表单、EDI、数字发票，从一开始就以结构化数据接收 读取这道工序本身变得不再必要 高。需要与交易对象协调，比较耗时

本文的主战场是 (1) 和 (2)。建议先做好 (1) 就已经能带来充分的日常效果，再根据成本效益来判断是否推进 (2)。(3) 会在第7章提及。

3. 基本流程 ── 从接收触发器到保存与通知

基本形态是「接收触发器 → 筛选 → 逐个附件循环 → 保存到 SharePoint → 通知」。

否是失败时共享邮箱收到新邮件时 V2order@自家域名通过触发器条件筛选发件人・主题过滤器・仅限有附件Apply to each逐个附件循环Is Inline = false且 扩展名为 .pdf ?不处理排除签名图片等SharePoint: 创建文件保存到 交易对象/年月 文件夹文件名包含接收时间发布到 Teams 频道 或 发送邮件通知记录保存位置链接・发件人・主题完成错误通知告知管理员处理失败

主要动作与设计要点如下表所示。

步骤 使用的触发器/动作 设计要点
接收检测 收到新邮件时 (V3) / 共享邮箱收到新邮件时 (V2) 同时打开「仅限有附件 (Only with Attachments)」和「包含附件 (Include Attachments)」。前者用于跳过没有附件的邮件，后者用于把附件内容包含到触发器的输出中，两者作用不同（附件较大时的替代结构见4.1章末尾）1
筛选 触发器的 From / 主题过滤器 (Subject Filter) 发件人地址、主题中的固定字符串（如「订单」等）应在触发器一侧指定。如果让触发器全部放行、再在后段条件分支中丢弃，即便是无关邮件也会消耗一次执行次数2
附件筛选 Apply to each + 条件（Is Inline / 扩展名） 对每个附件，只处理 Is Inline 为 false 且文件名以 .pdf 结尾的附件（详见下一章）4
保存 SharePoint「创建文件 (Create file)」 指定已有的文档库并上传文件。文件夹按「交易对象/年月」等规则决定，文件名中包含接收时间以保证唯一5
通知 Teams「在聊天或频道中发布消息」/ Outlook「发送邮件 (V2)」 记录保存位置的链接、发件人、主题。通知的目的是「不用主动去查看也能注意到」，因此应集中发到负责团队的频道8

如果目标文件夹要按「交易对象/年月」这样的规则动态决定，也不要忘记在流程一侧保证目标文件夹的存在。新交易对象的第一封邮件，或每月第一封邮件到达时，目标文件夹往往还不存在。SharePoint 连接器提供「创建新文件夹 (Create new folder)」动作，可以一次性创建文件夹路径5，在「创建文件」之前加入准备文件夹的步骤，就能避免在这里因保存卡住的事故。

之所以将保存位置选为 SharePoint 而不是传统的文件服务器，是因为它可以从云端流程直接写入、可以通过链接通知、后续也更容易与 AI Builder 或搜索功能组合使用。如果因客观情况只能用本地文件服务器，也可以通过本地数据网关来实现，但这会让配置变得更复杂，因此如果条件允许，建议把保存位置整体迁移到 SharePoint。

关于流程整体的错误处理思路（失败时的通知、执行历史的确认），在另一篇文章「用 Power Automate 实现业务自动化 ── 云端流程与桌面流程的分工及错误处理设计」中有详细说明。

4. 常见坑点与应对方法

第一个能跑起来的流程，半天时间就能搭建出来。问题在于此后——能否经受住实际运营，取决于是否堵住了下面这些坑点。

4.1 签名・徽标图片被当作「附件」保存

这是最常见的咨询之一。嵌入邮件正文中的签名图片或公司徽标，在数据层面被视为内联附件，因此如果仅凭「有附件」这一条件来保存，就会连同真正需要的 PDF 一起，保存下大量类似 image001.png 的文件。

在 Office 365 Outlook 连接器中，触发器和动作返回的附件元数据中包含 Id・Name・Content Type・Size・Is Inline，这些信息无论「包含附件」的设置如何都始终可以获取。Is Inline 为 true 的就是内联附件。4

应对方法分两层。

  1. 在 Apply to each 中，用条件动作只放行 Is Inline 为 false 的附件
  2. 再确认文件名末尾是否为 .pdf（除了交易对象在正文中以图片形式贴出单据这种少见情况外，这样几乎能可靠地筛选出目标）

另外，如果日常会收到体积较大或数量较多的附件，也可以选择把触发器的「包含附件」关闭，先用元数据筛选出目标，再用「获取附件 (V2)」动作逐个单独获取所需附件的结构。1 由于附件的元数据（Is Inline 及名称）无论「包含附件」的设置如何都能获取，因此无论采用哪种结构，筛选逻辑都是一样的。4 这种方式能让触发器传递的数据保持精简，当流程规模变大、附件处理变重时，可以考虑切换到这种形态。

4.2 目标邮件的筛选 ── 专用地址 + 共享邮箱

负责人个人的收件箱，也会收到大量与订单无关的邮件。无论用发件人还是主题多么努力去筛选，只要交易对象改变了邮件的写法，就会出现遗漏。根本性的对策是准备一个专门用于接单的地址，让交易对象把邮件发到那里。

此时，接口应设为共享邮箱。原因有两个。

  • 可以把邮件接收入口与负责人个人的邮箱分离。这能防止负责人调岗或离职时接口连同邮件一起消失，或者继任者无法查看过往邮件的事故
  • 共享邮箱本身不需要单独的许可证，只要访问它的用户拥有许可证即可9

触发器使用「共享邮箱收到新邮件时 (V2)」。前提条件是，用于流程连接的账户必须拥有该共享邮箱的访问权限。需要注意的是，授予权限后到平台侧生效可能需要约2小时，此外 Microsoft 365 组的地址不能被指定为共享邮箱。3

不过要注意，改为共享邮箱并不意味着流程就此摆脱了对个人的依赖。流程的连接（对 Outlook 的身份验证）仍然与创建该连接的用户账户绑定，共享出去的连接也只能在该流程内使用，其他所有者也无法更改另一位所有者创建的连接的凭据。10 也就是说，如果用于连接的账户因离职而被停用，即便接口是共享邮箱，流程依然会停止运行。应尽量用与特定员工任期无关的运营专用账户来创建连接，同时设置共同所有者，以便在必要时由其他所有者用自己的连接进行替换，维持流程的运行。

4.3 同名文件的覆盖与重复

名为「订单.pdf」的附件，会从多个交易对象反复发来。如果按接收到的原始文件名保存，同名文件的冲突必然会发生。保存时的文件名应根据接收邮件的信息机械化地组合成唯一值。实务中，采用「接收时间（精确到秒）+ 发件人域名 + 原始文件名」这样的命名方式，几乎可以避免冲突，也方便后续与邮件核对。

此外，在流程修改后进行测试性的手动重新执行等场景中，也会出现同一封邮件被处理两次的情况。如果采用基于接收时间的命名方式，这种情况下写入目标只会是源自同一封邮件的同名文件，不会牵连并覆盖其他交易对象的文件。不过，第二次写入同名文件本身仍然是一种冲突（无论结果是覆盖还是失败，内容都是相同的），如果想真正检测重复处理本身，可以把触发器输出中包含的邮件 ID 记录到目标清单的列或文件名中，以便机械化地核对是否已经处理过。1

4.4 检测漏处理 ── 能否发现「触发器未运行的邮件」

这一点容易被忽略，但接收触发器并非万能。文档中明确记载了以下限制情形。

  • 总大小超过 Exchange 管理员设置的上限或 50 MB 中较小者的邮件，会被触发器跳过。受保护的邮件（加密邮件），以及正文或附件损坏的邮件，也可能被跳过1
  • 如果同时收到大量邮件，由于系统侧的限制，极少数情况下触发器可能会漏掉部分邮件11

也就是说，可能出现的不是「流程出错」，而是「根本没有被执行」的邮件。仅监控错误通知是无法察觉这种遗漏的。现实的对策是，除了流程成功/失败的通知外，仍保留由人定期检查收件箱的运营方式（让流程把已处理的邮件移动到文件夹，这样留在收件箱中的邮件就能被识别为未处理）。邮件本身的大小上限由 Exchange Online 侧的设置决定，默认接收上限为 36 MB，管理员可在 1～150 MB 范围内调整。对于经常往来大容量附件的交易对象，可以考虑改用后文提到的文件共享链接等其他交接方式。12

5. 是否要做到读取内容（自动化转录）── AI Builder 的文档处理

保存与通知开始顺畅运行之后，接下来会想要的就是「把 PDF 的内容读取出来并写入台账」这一步的自动化。这时要用到的是 AI Builder 的文档处理。

5.1 预构建模型与自定义模型

AI Builder 为发票提供了预构建的发票处理模型。发票编号、开票日期、付款期限、交易对象名称、总金额、明细行等常见字段，无需训练模型即可直接提取，支持的语言中也包含日语。输入格式为 JPEG/PNG/PDF，文件大小限制为 20 MB。13

另一方面，对于像订单这样各公司版式不同的单据，或者即使是发票也想提取标准字段之外的项目（如自家的管理编号）时，则需要构建文档处理自定义模型。可从「固定模板文档」「通用文档」「发票（预构建模型的扩展）」三种类型中选择，把版式相同的单据归为一个集合，每个集合上传至少5份样本文档，通过标注要提取的字段和表格来进行训练。14

两者接入流程都很简单：发票处理模型使用「从发票中提取信息」动作，自定义模型使用「处理文档」动作，只需把保存在 SharePoint 中的 PDF 文件内容传给该动作即可。158

5.2 精度与异常处理 ── 通过置信度分数分流至人工确认

在内容读取自动化中最重要的一点，是要以「提取可能会出错」为前提来设计。AI Builder 的提取结果会为每个字段附带一个0～1之间的置信度分数。实务中会利用这个分数来对流程进行分支。15

  • 分数较高（例如0.9以上）→ 直接写入台账，通知内容为「已自动处理」
  • 分数较低 → 在台账中标记为「待确认」，并通知负责人「请核对这一项」

微软的官方文档本身也介绍了一种组合预构建模型与自定义模型的结构示例：当置信度分数较低时，回退到另一个模型进行处理。13 采用「能自动读取的部分就自动处理，读不出来的部分才由人核对」这样的设计，就不必追求100%的精度，从而大幅降低了导入的门槛。

5.3 许可证与积分 ── 这里必须事先确认

AI Builder 的动作每次运行都会消耗消费型的容量。这种容量以往被称为 AI Builder 积分，可以通过 AI Builder 容量附加组件（每个附加组件每月100万积分）获得，此外 Power Automate Premium 等高级许可证也会附带少量积分（Power Automate Premium 附带5,000积分）。积分以租户为单位汇集，并分配到各环境中使用。如果环境没有分配容量，流程就会因 NoCapacity 等错误而停止。6

不过，目前这一体系正处于过渡期。2025年10月宣布了 AI Builder 积分的分阶段终止：高级许可证附带的种子积分将于2026年11月1日终止，新客户也无法再购买 AI Builder 容量附加组件，而是改为购买 Copilot 积分。AI Builder 的功能本身仍可以继续用 Copilot 积分使用，但在云端流程中，会优先消耗 AI Builder 积分，用尽后才会消耗 Copilot 积分。716

简而言之，「要做到内容读取，就需要额外成本，而这套体系目前正在发生变化」。这里整理一份导入判断的参考表。

情况 判断
每月单据数量少，转录也只需几分钟即可完成 可以放弃内容读取，做到保存・通知（第3章）即可
以发票为主，数量多，转录负担大 先从预构建的发票处理模型开始尝试。无需训练即可立即确认精度13
以订单等各公司版式不同的单据为主 使用文档处理自定义模型。版式种类越多，训练与维护的成本就越大，需要提前考虑到这一点14
想把提取结果无人值守地直接写入核心系统 不建议这样做。必须插入基于置信度分数的人工确认分支
交易对象数量多，单据版式还在持续增加 在因维护读取模型而疲于奔命之前，应考虑改变接收方式本身（第7章）

6. 遇到密码保护的 ZIP（PPAP）── 这不该由流程来解决

「附件是以密码保护的 ZIP 送达的，流程能解压吗」也是一个常见问题。结论是：请不要试图在流程内解决这个问题。

密码保护 ZIP 这种运营方式，是建立在「密码通过另一封邮件送达，由人读取后手动输入才能打开」这一前提之上的。密码通知的时机和格式完全取决于对方，这套机制本来就没有考虑到机器处理。如果硬要把这一步自动化，就会背上解析密码邮件、保存密码这类原本完全不需要的、颇具风险的机制。

归根结底，PPAP 在同一路径上同时发送密钥和货物，作为安全对策本身意义就不大，其更大的危害在于让内容绕过接收方的病毒检测。这一问题及其替代方案（文件共享链接等），在另一篇文章「为什么在邮件安全方面 PPAP 不可取？正确的做法是什么？」中有详细说明。从自动化的角度来说，以 PPAP 形式送达的单据，正是「应该协商改变接收方式的对象列表」中的首位。随着 PPAP 逐渐被淘汰的大趋势，向交易对象提出「出于自动化处理的考虑，希望改用明文 PDF 附件或文件共享链接，而不是密码保护的 ZIP」这类请求，也比以前更容易被接受了。

7. 更进一步 ── 邮件附件运营方式的局限与分阶段迁移

在把保存、通知、读取都整理完善之后，剩下的就是「本质上仍在通过邮件附件交换单据」这件事本身的局限性。

  • 单据的版式有多少交易对象就有多少种，交易对象越多，读取模型的维护负担就越重
  • 提取精度永远达不到100%，因此人工确认这道工序会永远存在
  • 邮件有可能送达失败（超出大小限制、被判定为垃圾邮件），因此漏处理的监控也会持续存在

无论把 Power Automate 的设计打磨得多精细，这些问题都不会消失。只要流程的起点仍是「把非结构化数据（PDF）发送给人」，读取和确认就会作为必要成本一直存在。正因如此，从中期来看，值得把从一开始就以结构化数据接收这一方向纳入视野，也就是分阶段迁移到 Web 接单表单、EDI，或者对发票而言的数字发票（Peppol / JP PINT）。

迁移不需要一次性全部切换。现实的做法是：从愿意配合的交易对象开始，逐步迁移到新的接收方式，其余部分则继续用邮件附件加自动化处理来承接，形成双轨并行的局面。这种分阶段迁移的设计，在「如何把传真接单迁移到 Web ── 双轨运营期间的设计与分阶段迁移的实务」中有说明，数字发票的机制则在「数字发票是什么？── 与「用邮件发送发票 PDF」有什么不同」中有整理。本文所介绍的流程，最好定位为在这一迁移期间、支撑「仍需通过邮件附件持续接收的那部分」的机制。

8. 总结

处理邮件收到的订单・发票 PDF，作为 Power Automate 自动化主题来说，属于比较入门的一类，但要让它经得起实际运营的考验，需要把握的要点是清晰的。

首先，把接口设为共享邮箱上的专用地址，把筛选条件尽量放到触发器一侧。附件的筛选采用 Is Inline 与扩展名两层判断，排除签名图片。文件名以接收时间为基础保证唯一，并以触发器可能会跳过邮件（超过50 MB、加密邮件、同时收到大量邮件）为前提，保留能够察觉遗漏的运营方式。以上是第一阶段。

如果要深入到内容读取，就使用 AI Builder 的预构建模型或自定义模型，配合置信度分数的分支，并事先确认消费型积分的成本以及过渡期中的许可证体系。同时，密码保护的 ZIP 不要试图在流程中解开，而应作为协商改变接收方式的对象。当邮件附件这种形式本身的局限性变得明显时，再考虑向 Web 表单、EDI、数字发票的分阶段迁移——按照这个顺序推进，就是一个可以稳步发展、不会带来大规模返工的领域。

相关文章

相关咨询领域

合同会社小村软件承接使用 Power Automate 进行邮件・单据处理自动化设计，以及面向接单业务数字化的分阶段迁移相关咨询。

参考链接

  1. Microsoft Learn, Office 365 Outlook - Connectors. 关于「收到新邮件时 (V3)」触发器的参数（Folder / From / Only with Attachments / Include Attachments / Subject Filter 等），以及触发器会跳过超过 Exchange 管理员设置上限或 50 MB 中较小者的邮件、受保护邮件的说明。 ↩ ↩2 ↩3 ↩4 ↩5

  2. Microsoft Learn, Trigger a cloud flow based on email properties. 关于「收到新邮件时 (V3)」触发器可用的筛选属性，以及不在触发器一侧而在条件分支中确认属性会导致无关邮件也消耗执行次数的说明。 ↩ ↩2

  3. Microsoft Learn, Office 365 Outlook - Connectors (Shared mailbox support / Known issues). 关于「共享邮箱收到新邮件时 (V2)」触发器需要连接账户拥有该共享邮箱的访问权限、权限授予后生效可能需要约2小时、Microsoft 365 组地址无法用作共享邮箱的说明。 ↩ ↩2

  4. Microsoft Learn, Office 365 Outlook - Connectors (Working with attachments). 关于附件元数据（Id / Name / Content Type / Size / Is Inline）无论「包含附件」设置如何都会返回、Is Inline 属性可用于判别内联附件的说明。 ↩ ↩2 ↩3 ↩4

  5. Microsoft Learn, Microsoft SharePoint Connector in Power Automate. 关于 SharePoint 连接器的「创建文件 (Create file)」动作用于向已有文档库上传文件、「创建新文件夹 (Create new folder)」动作用于创建文件夹或文件夹路径的说明。 ↩ ↩2 ↩3

  6. Microsoft Learn, Licensing and AI Builder credits. 关于 AI Builder 积分的获取途径（容量附加组件每月100万积分、Power Automate Premium 附带5,000积分）、以租户为单位汇集并分配到环境、容量不足时出现 NoCapacity 等错误，以及种子积分将于2026年11月1日终止的说明。 ↩ ↩2

  7. Microsoft Learn, End of AI Builder credits. 关于2025年10月宣布的 AI Builder 积分分阶段终止，以及 AI Builder 功能本身仍可继续通过 Copilot 积分使用的说明。 ↩ ↩2

  8. Microsoft Learn, Use a document processing model in Power Automate. 关于云端流程中「处理文档」动作的使用方法，以及用 Teams「在聊天或频道中发布消息」动作通知提取结果的结构示例的说明。 ↩ ↩2

  9. Microsoft Learn, About shared mailboxes in Microsoft 365. 关于共享邮箱本身不需要单独许可证、访问用户需要拥有带许可证的邮箱，以及不直接用共享邮箱账户登录的运营方式的说明。 ↩

  10. Microsoft Learn, Share a cloud flow. 关于流程的连接与创建者账户绑定、共享出去的连接只能在该流程内使用、共同所有者无法更改其他所有者创建的连接凭据，以及添加共同所有者的说明。 ↩

  11. Microsoft Learn, Office 365 Outlook - Connectors (Known issues and limitations with triggers). 关于同时收到大量邮件时，由于系统侧限制，邮件触发器极少数情况下会漏掉邮件的说明。 ↩

  12. Microsoft Learn, Exchange Online limits. 关于邮箱默认的最大邮件大小（发送 35 MB / 接收 36 MB），以及管理员可在 1～150 MB 范围内设置自定义上限的说明。 ↩

  13. Microsoft Learn, Invoice processing prebuilt AI model. 关于预构建发票处理模型的提取字段、支持语言（含日语）、输入格式（JPEG/PNG/PDF，20 MB 以下），以及将置信度分数较低的字段回退到自定义模型的结构示例的说明。 ↩ ↩2 ↩3

  14. Microsoft Learn, Create a document processing custom model. 关于文档处理自定义模型的文档类型（固定模板文档/通用文档/发票）、每个集合需要至少5份样本文档，以及提取字段与表格定义的说明。 ↩ ↩2

  15. Microsoft Learn, Use the invoice processing prebuilt model in Power Automate. 关于云端流程中「从发票中提取信息」动作的使用方法，以及每个字段会返回0～1置信度分数的说明。 ↩ ↩2

  16. Microsoft Learn, Power Platform licensing FAQs. 关于云端流程的 AI Builder 功能会优先消耗 AI Builder 积分，在积分不足或用尽后再消耗 Copilot 积分的说明。 ↩

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

发送到共享邮箱的邮件，也能触发 Power Automate 的流程吗？
可以。Office 365 Outlook 连接器有一个专用触发器「共享邮箱收到新邮件时 (V2)」，可以用发送到接单用共享地址的邮件作为流程的起点。前提是，用于连接的账户必须拥有该共享邮箱的访问权限。需要注意的是，刚授予权限后可能需要约2小时才能生效，并且 Microsoft 365 组的地址不能被指定为共享邮箱。用共享邮箱而不是负责人个人的收件箱来接收，能让接口更容易交接，但由于流程的连接本身与创建者的账户绑定，因此也需要同时确定连接所用账户的管理方式，以及共同所有者的设置。
邮件签名中的图片为什么会被当作附件保存下来？
嵌入邮件正文中的签名图片或徽标，从数据角度来看也属于附件的一种（内联附件）。如果仅凭「有附件」这一条件来处理，本来想要的 PDF 就会连同签名的 PNG 或 GIF 一起被保存下来。应对方法是利用 Office 365 Outlook 连接器为每个附件返回的 Is Inline 元数据作为条件分支，只处理 Is Inline 为 false 的附件。再叠加判断文件扩展名是否为 .pdf，就能更可靠地缩小处理范围。
要用 AI Builder 把 PDF 内容的读取也自动化，需要准备什么？
AI Builder 提供了预构建的发票处理模型，可以从发票中提取发票编号、日期、总金额等信息，并且支持日语发票。对于订单等各公司格式不同的单据，则需要用文档处理自定义模型，通过样本文档（每种版式至少5份）进行训练。运行时需要 AI Builder 积分等消费型容量，如果环境没有分配容量，流程就会因错误而停止。另外，2025年10月已宣布 AI Builder 积分将逐步终止，今后会转向 Copilot 积分，因此在新引入时请务必确认最新的许可证体系。
以密码保护的 ZIP（PPAP）形式送达的附件，流程也能处理吗？
密码保护的 ZIP 从根本上就与自动化处理不合拍，不应该以「在流程内解压」为前提来设计。因为密码通过另一封邮件送达、必须由人读取后才能打开这一运营方式，本身就没有考虑到机器处理。虽然可以把 ZIP 原样保存到人可以打开的位置，但这样并不能实现转录或读取的自动化。现实中，本质性的对策是与交易对象协商停止使用 PPAP，也就是改变文件交接的方式本身。PPAP 在安全性方面本身也存在不少问题，因此另一篇整理了 PPAP 问题点的文章，也可以作为协商时的参考材料。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

联系我们
返回博客列表