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

用 Microsoft Forms 搭建社内申请・请求的受理入口 ── 把邮件与口头请求汇总到表单

· · Power Automate, Microsoft Forms, Forms, SharePoint, Teams, Microsoft 365, 云端流程, 申请表单, 业务自动化, 技术咨询

「希望帮忙创建服务器账户」通过邮件送达，「打印机不太好使，麻烦看一下」是在走廊擦肩而过时被口头拜托的，「这张发票麻烦处理一下」则是贴在桌上的便利贴。我们经常收到来自信息系统部门、行政部、财务部这类承接社内请求的部门的咨询，希望能想办法改善这种状况。

提出请求的一方以为「说过了对方就会去办」，而接收的一方却只能依靠自己的记忆和邮箱。偏偏是在忙碌的日子里漏掉一件，直到「那件事怎么样了？」被问起才发觉。如果公司已经导入了 Microsoft 365，这类问题可以通过以 Microsoft Forms 作为受理入口、再用 Power Automate 自动完成通知与记录的「受理套路」得到相当程度的解决。本文将整理表单设计的实务、文件上传的限制、受理流程的基本形态，以及 Forms 单独使用的局限与转记到列表成为标准做法的原因。审批・决裁本身的设计由另一篇文章《用 Power Automate 搭建审批流程 ── 将纸质与邮件签核、申请电子化》专门负责，因此本文聚焦于「受理」。

目标读者与前提环境

  • 目标读者: 信息系统部门、行政部、财务部等在社内承接请求与申请的负责人。本文按未接触过 Power Automate 的读者来撰写。
  • 前提环境: 已导入 Microsoft 365，并可使用 Microsoft Forms 与 SharePoint。创建流程需要能够使用 Power Automate 的许可证，但本文中用到的 Forms・SharePoint・Outlook・Teams 连接器都属于标准连接器范围，不会出现高级连接器(相关边界的梳理见《Power Automate 的许可证与标准/高级连接器的边界》)。
  • 所需权限: 需要是放置表单的组(团队)的成员，并且能够在转记目标的 SharePoint 网站中创建列表。不需要租户管理员权限，但回答者姓名记录的默认值，以及是否允许外部共享，由管理员设置决定。1
  • 本文将搭建的内容: 一个受理请求的表单、一个作为受理台账的 SharePoint 列表，以及一条在受理时运行的云端流程。

1. 先说结论

  • 请求的受理入口需要把「输入的形式」与「记录的存放位置」一并设计。现实中最小的可行结构是「用 Forms 受理 → 通过 Power Automate 转记到 SharePoint 列表 → 通知」。
  • 流程的基本形态是触发器「提交新响应时」与操作「获取响应详细信息」这两个步骤。Forms 连接器只有这一个触发器和一个操作(再加上获取表单详情)，需要记住的东西并不多。23
  • 公开范围原则上应为组织内限定。启用「记录姓名」后，回答者的姓名和邮箱地址会被自动记录，无需再让对方填写姓名・所属部门。在向组织外开放的设置下，回答会变成匿名，无法记录是谁提交的。4
  • 文件上传问题仅限组织内限定的表单专用。单个问题最多可以接收 10 个文件，单个文件的上限可以从 10MB・100MB・1GB 中选择，文件会保存到 OneDrive for Business 中。5
  • 把 Forms 定位为纯粹的受理入口，是让它长久好用的诀窍。它没有提交后编辑或确认进度的功能，回答列表也没有状态管理机制，因此台账应交给 SharePoint 列表来承担。6
  • 回答件数的上限，在职场・学校账户下最多为 5,000,000 条，对社内使用而言几乎相当于无限，但一旦超过 50,000 条，概要图表与单条回答的查看功能就会失效。比起上限，「一览管理能力弱」这一点会先成为瓶颈。7
  • 需要从社外受理并附带附件、件数众多且希望与核心系统联动、希望向申请人公开进度 ── 从这一带开始，就超出了 Forms 的守备范围。具体的界限整理在第 7 章的判断表中。

2. 邮件与口头请求究竟哪里有问题

用邮件和口头方式接收请求的运作方式，问题出在光靠负责人的努力也无法解决的结构性因素上。

  • 遗漏在结构上必然发生。请求会通过收件箱・聊天・口头・便利贴等各不相同的渠道送达，因此哪里都不存在「全部请求的清单」。能否一件不漏，完全押注在个人的记忆力上。
  • 格式各不相同，导致往返沟通增多。像「麻烦设置一下电脑」这种只有一句话的邮件，看不出对象电脑、希望日期、原因，因此会产生反复询问的往返。每次请求都要重新想起必要事项并写下来，对提出请求的一方而言也是负担。
  • 状态不可见，容易变成「说了没说」的争执。申请人无法看到请求是否已被受理、是否已经着手处理、什么时候能完成。一旦负责人说「没听说过」，就会陷入各执一词的争论。催促与确认这类往来本身，就在消耗双方的时间。
  • 无法统计。由于没有留下每月有多少请求、时间都花在了什么上面的数据，「人手不够」「这个系统的咨询太多了」这类说法就没法用数字来证明。

只要建立「把请求入口统一为一个，用固定形式接收必要事项，受理的瞬间就留下记录与通知」这样的机制，这些问题就能一并得到解决。之所以选用 Forms 和 Power Automate，是因为如果已经导入了 Microsoft 365，往往可以在不增加额外费用的范围内搭建这套机制(本文用到的 Forms・SharePoint・Outlook・Teams 各连接器都属于标准连接器范围。许可证的思路已在《Power Automate 的许可证与标准/高级连接器的边界》中整理)。

3. 表单设计的实务

让填写者「做选择」是基本原则

表单设计的目标，是让申请人能够毫不犹豫地提交，同时受理方也能拿到无需再次询问就可以着手处理的信息。原则是「用选项接收，文本尽量少」。

  • 请求种类做成选项。像「创建账户/PC・外设/软件安装/其他」这样，把之后要用于统计和流程分支的维度，用选项确定下来。
  • 期限用日期问题接收。这样可以消除「尽快」「本周内」这类模糊表达，还能在流程一侧用于提醒(营业日与截止日的处理方式，参见《用 Power Automate 设计定期执行流程 ── 月末处理・营业日判定・提醒的实务》)。
  • 大致的做法是把自由填写集中到「补充说明」这一个问题上。这里有一个实务上需要注意的地方：如果单行文本(简短回答)中输入超过 255 个字符，会出现流程时而正常运行、时而不运行的已知问题。可能会输入长文的问题，从一开始就应该设为「长回答」(多行文本)。8

还有一点是「不要让人写太多」。受理表单的作用是不漏掉任何一件请求，而不是当场吸收全部信息。问题太多的表单会让人重新退回到口头或邮件方式。需要详细了解情况的案件，前提是受理后由负责人另行联系，表单本身应控制在几分钟就能填完的粒度。

用分支避免出现「无关的问题」

如果依请求种类不同，需要询问的内容也不同，就使用分支(branching)。根据选项的回答，可以切换接下来显示的问题或分节，比如「创建账户就问对象系统与权限，设备故障就问资产编号与症状」，只把与回答者相关的问题展示出来。分支只能跳转到后面的问题(不能跳回前面的问题)，因此把通用问题放在前半部分、按种类划分的问题分成不同分节放在后半部分，是比较容易搭建的结构。9

公开范围与回答者信息 ── 组织内限定与匿名的区别

Forms 的公开范围有 3 种。4

公开范围 可以回答的人 回答者的记录
所有用户均可回答 只要知道链接，组织外的人也能回答 匿名。不会记录是谁提交的
仅限本组织内的用户回答 只有用组织账户登录的人 通过「记录姓名」自动记录姓名・邮箱地址
组织内的特定用户可以回答 只有指定的用户・组 同上

社内申请・请求的受理入口，原则上应采用组织内限定。理由有三个。

  1. 不必再让对方填写「谁提交的」。启用「记录姓名」后，回答者的姓名和邮箱地址会自动附加到回答上。姓名・所属・联系方式这种「每次都要写同样内容」的问题，可以整体删除。4
  2. 有些功能只有组织内限定才能使用，比如每人限答一次、文件上传等。「每人限提交一条回答」也只有在组织内限定时才能设置。4
  3. 可以通过流程回复申请人。由于响应详细信息中会包含回答者的邮箱地址(Responders’ Email)，因此可以直接发送受理完成邮件(第 5 章)。匿名表单做不到这一点。10

另外，作为组织整体的默认值，是否记录回答者姓名，可以由管理员在 Microsoft 365 管理中心的 Forms 设置(「默认记录姓名」)中控制。是否作为租户允许外部共享(向组织外发送回答请求)本身，也是同一画面中的设置。如果公司有「社内问卷调查默认匿名」之类的政策，也应事先确认这一点。1

即便如此，如果确实需要向组织外开放，也有必要事先整理清楚会失去什么。

  • 不会记录是谁提交的。向组织外开放的表单，其回答会变成匿名，回答者不登录也能提交。11 无论是冒充还是重复提交，表单一侧都无法防止。「每人限提交一条回答」这个限制也只有组织内限定时才能使用，因此同一个人可以反复提交多次。4
  • 无法接收附件。文件上传问题仅限组织内限定的表单专用。5
  • 无法从流程回复申请人。由于获取不到回答者的邮箱地址(Responders’ Email)，因此无法使用受理完成邮件自动回复这个效果最好的机制(如果改为用自由填写的方式让对方写邮箱地址，一旦收件地址填错，邮件就会直接发不出去)。
  • 有时本身就不被允许。由于外部共享可以在租户的管理员设置中被禁止，因此会发生「即使发出了链接，对方也无法回答」这类事故。请事先向管理员确认。1

面向社外时，安全范围仅限于「件数不多、既不需要附件也不需要身份确认的问卷式受理」。一旦超出这个范围，就应按第 7 章的判断表，转向 Web 表单一侧的设计。

不要让表单停留在个人名下 ── 为创建者离职做好准备

这是一个容易被忽视、但很重要的论点。个人创建的表单会与该人的账户绑定，一旦因离职等原因账户从租户中被删除，与账户相关的数据会在删除后 30 天消失。11 受理表单是业务的入口，不应作为负责人个人的所有物，而应作为组(团队)的表单来创建，或者事先确定好在调岗・离职时移交所有权的运作方式。8

有一点需要在流程一侧注意。组表单不会显示在 Power Automate 触发器的表单 ID 列表中，因此需要复制表单编辑画面 URL 中 FormId= 之后的值，作为表单 ID 手动输入。3 虽然多了一道手续，但避免依赖个人的价值更大。

4. 文件上传的规格与限制

像「附上报价单 PDF 提交采购申请」「附上错误画面截图提交故障报告」这样，请求中带有附件的情况很多。Forms 的文件上传问题的规格，需要准确掌握。5

  • 仅限组织内限定的表单专用。只有当公开范围是「仅限本组织内的用户回答」或「组织内的特定用户可以回答」时才能添加，向组织外开放的表单无法使用。也就是说，Forms 不能用于「让社外交易方带附件提交申请」这类用途。
  • 单个问题最多可以接收 10 个文件，每个文件的大小上限可以从 10MB・100MB・1GB 中选择。
  • 可以限制文件类型。可以从 Word・Excel・PowerPoint・PDF・图片・视频・音频中选择允许的类型，从而实现「报价单仅接收 PDF」这样的受理方式。
  • 保存位置会因表单所有者而不同。如果是个人表单，回答者上传的文件会保存到创建者 OneDrive for Business 中「应用 > Microsoft Forms > (表单名) > (问题名)」文件夹；如果是第 3 章推荐的组表单，则会保存到组的 SharePoint 网站中，逐渐积累起来。

从流程中处理上传文件需要多一道手续。「获取响应详细信息」返回的上传问题回答，是包含文件名和 ID 的 JSON 字符串，因此需要通过「解析 JSON(Parse JSON)」提供架构进行分解，再用类似 first(body('Parse_JSON'))?['id'] 这样的表达式取出文件 ID，然后传给获取文件的操作。10

架构的制作方法，按照官方步骤从实物生成最为可靠。①保存流程并进行测试执行，从表单上传一个文件 → ②在执行历史记录中打开「获取响应详细信息」，复制该上传问题的输出 → ③粘贴到「解析 JSON」操作的「从示例生成」中，共 3 个步骤。10

如果想手动编写，只需要声明会用到的属性的最小形式就够了(即使返回了未声明的属性，解析 JSON 也不会出错)。由于制作共享链接只需要文件 ID，实质上只需要下面这些内容。

{
    "type": "array",
    "items": {
        "type": "object",
        "properties": {
            "id":   { "type": "string" },
            "name": { "type": "string" }
        },
        "required": [ "id" ]
    }
}

这里最需要注意的一点是，回答会以数组形式返回。官方表达式之所以写成 first(body('Parse_JSON'))?['id'] 这种取出首个元素的形式，原因正在于此。10 另外，first(...) 是以文件数量为 1 为前提的写法。对于允许多个文件的问题，回答会以逐个文件对象排列而成的数组形式返回，因此需要用 Apply to each 遍历解析结果，逐个文件获取(如果一个附件就足够，把问题一侧的上限设为 1 个文件会更简单)。此外，获取文件时使用的连接器要与上面的保存位置相匹配。个人表单用 OneDrive for Business 连接器；组表单的保存位置是组的 SharePoint 网站，因此要用 SharePoint 连接器指定该网站来获取。对组表单用 OneDrive 连接器去查找文件却怎么也找不到，是一个常见的组合错误。

如果要把收到的文件附加到审批请求中传递下去，需要把文件内容以二进制形式传给附件字段。12 不过，审批操作能通过邮件附加的文件上限是 5MB，超出这个大小的附件，审批人需要在 Power Automate 门户的审批列表中查看。8 较大的文件不要用附件方式传递，而是保存到 SharePoint 后传递链接，更为可靠。

5. 用 Power Automate 驱动受理

基本形态是 2 个步骤 + 3 个出口

即便回答送达，Forms 默认也不会通知任何人(虽然有面向表单所有者的通知设置，但收件人和内容都无法自行选择10)。把受理当作业务来运转，是 Power Automate 的工作。流程的基本形态是：用触发器「提交新响应时」指定表单，接着用「获取响应详细信息」把各个问题的回答取出为动态内容，共两个步骤。2 在此之后的出口有三个 ── 「记录到台账」「向申请人发送受理通知」「向负责团队发送通知」。

是否申请人在 Forms 中提交组织内限定・已登录提交新响应时云端流程启动获取响应详细信息把回答转为动态内容创建 SharePoint 列表项目状态－已受理向申请人发送受理完成邮件插入回答内容的副本发布到负责团队的 Teams 频道是否为需要审批的类别?进入审批流程开始并等待审批分配负责人处理将结果写回列表通过状态列更新处理进度

概念图和实际画面之间的落差，是最容易让人困惑的地方，因此把按这张图原样搭建时的点击步骤也写下来。请事先创建好作为转记目标的 SharePoint 列表。

  1. 打开 Power Automate 门户，从左侧菜单的「创建」中选择「自动化的云端流程」。输入流程名称。
  2. 在触发器的搜索栏中输入「Forms」，选择「提交新响应时」。2
  3. 在触发器的「表单 ID」中选择表单。组表单不会出现在列表中，需要粘贴表单编辑画面 URL 中 FormId= 之后的部分(第 3 章)。3
  4. 「新步骤」→ 搜索栏中输入「Forms」→ 操作「获取响应详细信息」。这里同样指定相同的表单，「响应 ID」中填入触发器的动态内容「响应 ID」(有时会自动填入)。2
  5. 「新步骤」→「SharePoint」→「创建项目」。选择网站地址和列表名称，把「获取响应详细信息」的动态内容(各问题的回答)分配到各列。状态列可以先填入 已受理 这样的固定值。
  6. 「新步骤」→「Office 365 Outlook」→「发送邮件 (V2)」。「收件人」中填入动态内容 Responders’ Email，正文中写入回答内容的副本以及大致所需天数。10
  7. 「新步骤」→「Microsoft Teams」→「在聊天或频道中发布消息」。选择负责团队的团队和频道，附上种类・期限・申请人以及指向列表项目的链接。
  8. 点击右上角的「保存」→「测试」开始手动测试，实际从表单提交一条数据。打开各步骤的输入输出，确认数值是否按预期填入。

追加通向审批的分支是在这之后的事。先只用上面的 1～8 步，跑通「提交一件就会登记到台账、给申请人发邮件、给团队发通知」这条主线，再叠加条件分支，会更加稳妥。

转记到 SharePoint 列表 ── 制作受理台账

受理的请求，会在流程的最开始逐行转记到 SharePoint 列表中。要点是让列表除了回答的副本之外，还持有表单中没有的「用于管理的列」。

列 内容 由谁更新
请求内容列(种类・期限・详情等) 原样转记 Forms 的回答 流程(受理时)
申请人 从 Responders’ Email 记录 流程(受理时)
状态 已受理/处理中/已完成/退回 负责团队
负责人 分配的负责人 负责团队
处理备注 经过・确认事项 负责团队

向申请人追加提问，以及处理经过，不要分散在邮件里，而是集中到这个列表(或与列表项目关联的 Teams 讨论串)中，「说了没说」的记录就能汇总到一个地方。如果按「状态＝未完成」创建视图，就能直接变成早会上使用的处理一览。转记到 Excel 也有模板可用10，但对于需要多人持续更新状态的台账，拥有视图・列类型・版本历史的列表更为合适。从 Excel 台账迁移到列表的思路，整理在《把 Excel 台账替换为 SharePoint 列表 ── 通过共享、历史记录与流程集成告别「台账损坏」》中。

受理通知 ── 在第一分钟内回复「已收到」

这是与邮件请求相比体感差异最大的地方。从流程中会发出两种通知。

  • 向申请人发送受理完成邮件。如果是组织内限定的表单，可以直接用 Outlook 连接器，把邮件发送到响应详细信息中包含的回答者邮箱地址(Responders’ Email)。10 正文中插入回答内容的副本，以及「3 个工作日内负责人会与您联系」这样的大致时间。申请人想要催促的原因，大多是「连有没有收到都不知道」，光这一封邮件就能大幅减少咨询。Forms 本身也有向回答者发送确认邮件的设置，但能把文案贴合业务的，是从流程发送这种方式。10
  • 向负责团队发送 Teams 通知。如果发送到个人邮箱，就会再次变成依赖特定个人，因此改为发布到负责团队的频道。附上种类・期限・申请人以及指向列表项目的链接，频道就能直接变成「新请求收件箱」。

与审批对接

像「购买软件需要上级审批」这样的种类，需要从受理流程对接到审批操作(开始并等待审批)。也有把 Forms 回答内容插入审批请求的模板，可以一路搭建到根据审批结果向申请人回复结果邮件的形式。10 审批的类型、超时与催办、审批记录的留存方式等设计要点，已在《用 Power Automate 搭建审批流程 ── 将纸质与邮件签核、申请电子化》中详细说明，请参考该文。等受理流程稳定运行起来之后，也应尽早为流程设置共同所有者，以及失败时的通知(错误处理的设计参见《Power Automate 的错误处理与重试设计 ── 防止「原本正常运行的流程不知不觉停止了」》)。

6. Forms 单独使用的局限 ── 所以转记到列表才是定式

如果想仅靠 Forms 就把受理完整地做完，会遇到下面这些壁垒。

  • 送出后的状态不可见。默认情况下，回答者无法在提交后修改内容。虽然在部分已推广的环境中，创建者一侧可以允许回答者本人保存・编辑回答，但那仅限于修改回答内容的手段。表单设置中准备的，只有受理的开始・结束时间以及每人限答一次这类内容6，并没有可以确认「自己的请求现在处于什么状态(已受理・处理中・已完成)」的画面，不妨认为它本来就不具备支撑「提交之后」的功能，会更贴近实际情况。在不允许编辑的环境中，如果修改是靠「再提交一次」来完成的，那么哪一份是最新的，就要由受理方来判断。
  • 回答列表的管理功能较弱。Forms 的回答画面是用于统计和查阅的，既不能拥有状态列，也不能设置负责人，也无法做到「只显示未处理的」。受理管理所需要的是把一览「持续更新下去」的功能，而这已经超出了 Forms 的守备范围。
  • 上限比起件数，更先从功能层面产生影响。职场・学校账户的表单，每个表单最多可以接收 5,000,000 条回答，问题最多 200 个，文本回答每题最多 4,000 字符(此外还有单次回答的文本回答合计不超过 200,000 字符的限制，但这是单个回答者在一次提交内会触及的上限种类，并不是回答积累起来才达到的)。实务中先受到影响的不是件数，而是功能限制 ── 一旦超过 50,000 条，概要图表・单条回答查看・打印等功能就会失效，只能通过 CSV 导出获取。7 社内受理场景中，几乎不会达到件数上限，但对于长期运营的表单来说，「把数据一直囤积在 Forms 里」这种设计本身就会带来影响。官方的建议是回答增多后先导出再清空回答11，无论如何，历史记录的存放位置都需要另外准备。

也就是说，Forms 作为「分发输入形式的工具」很优秀，但并不是「管理受理之后的工具」。Forms 是受理入口，台账与状态管理交给 SharePoint 列表，通知与联动交给 Power Automate，这样的分工是沿着各自擅长领域而来的定式。

7. 用 Forms 受理到什么程度为止 ── 判断表

受理入口的工具配置是分阶段的。整理成表格作为参考。

情况 判断
来自社内的请求・申请，问题数在 10 个左右以内。附件仅来自社内用户 Forms + 流程 + 转记到列表已经足够。本文所述的结构
列较多的定型申请，且填写者仅限特定部门、熟悉列表操作 直接用 SharePoint 列表的表单受理。不再需要转记，输入与数据的类型也能统一
只想把每次的审批电子化(不需要受理台账) Teams 的审批应用就够了，也不需要创建流程
想接收来自社外(交易方・客户)的申请。不需要附件 用 Forms 的匿名表单也能受理，但回答者的记录・防冒充・输入校验都比较弱。件数少的话可以采用
想从社外接收带附件的申请，需要输入校验・编号・签发受理编号 Forms 中附件功能仅限组织内使用，因此无法实现。5 属于并用 OneDrive/SharePoint 文件请求，或委托开发 Web 表单的领域
件数较多，希望从受理一直对接到核心系统的登录・进度公开・SLA 管理 属于帮助台/工作流的专用系统或委托开发领域。应把 Forms 定位为初期的临时受理入口

从判断的直觉上说，可以概括为「只要申请人还在社内，就能靠 Forms 撑住；一旦牵涉到社外，就要改变设计」。关于把与社外之间纸质・传真・邮件附件的往来连同受理入口一并重新审视的话题，已在《把传真订单迁移到 Web ── 双轨运行期的设计与分阶段迁移实务》与《用 Power Automate 自动处理邮件收到的订单・发票 PDF ── 保存、分类、通知与读取的设计》中讨论过。

8. 总结

邮件与口头请求之所以让人痛苦，是因为请求的全貌无处可查、格式不统一、状态又看不见。用 Microsoft Forms 把入口统一为一个，通过组织内限定加姓名记录把「谁提交的」自动化，再由 Power Automate 在受理的瞬间返回台账记录与受理通知。光凭这一套模式，「那件事怎么样了？」这类往来就会大幅消失。

设计的要点在于：以选项为主、不让人写太多的表单，理解组织内限定与匿名的区别，掌握文件上传的限制(仅限组织内・最多 10 个文件・单个文件最大 1GB)，以及不要期待 Forms 能充当台账。Forms 是受理入口，列表是台账，流程负责通知与联动 ── 只要守住这个分工的受理体系，即使负责人更替，也能长久运转下去。而当来自社外的受理、附件，以及件数与联动需求逐渐膨胀起来时，就是该考虑 Web 表单开发或专用系统的时机了。

下一步 ── 制作第一个表单时的核对清单

如果一开始就想把所有请求汇总到一个表单里，问题会越来越多，最终谁都不会去用。请先只用一种请求把流程跑通。

  • 只选一种作为目标请求(件数多、格式不统一的请求比较适合)
  • 把问题控制在 5～10 个以内。请求种类・期限・补充说明这 3 项必须包含在内
  • 自由填写设为「长回答」(为避免单行文本的 255 字符问题。第 3 章)
  • 把公开范围设为「组织内限定」，并开启「记录姓名」
  • 不要做成个人表单，而是作为组(团队)的表单来创建
  • 先创建作为转记目标的 SharePoint 列表。必须包含状态・负责人・处理备注这 3 列
  • 按「获取响应详细信息 → 创建项目 → 受理完成邮件 → 发布 Teams 消息」的顺序搭建流程，通过测试执行跑通一条数据
  • 在受理完成邮件中写明「到什么时候会发生什么」
  • 为流程添加至少一名共同所有者(以便创建者休假时也能修复)
  • 运行 2 周，把产生了反复询问的项目补充到表单的问题中

做到这一步之后，再逐一增加请求种类。要增加的不是表单的问题，而是种类的选项与分支。

相关文章

相关咨询领域

合同会社小村软件提供从活用 Microsoft 365 搭建社内业务受理・台账・通知机制的咨询，到 Forms 无法覆盖的社外用 Web 表单・业务系统开发的全方位服务。

参考链接

  1. Microsoft Learn, Administrator settings for Microsoft Forms。关于管理员可以在 Microsoft 365 管理中心中控制是否将记录回答者姓名设为组织的默认值(「默认记录姓名」，默认开启)、是否允许外部共享(向组织外发送回答请求・共同编辑等)的说明。 ↩ ↩2 ↩3

  2. Microsoft Learn, Overview of flows with Microsoft Forms。关于 Forms 连接器拥有触发器「提交新响应时」与操作「获取响应详细信息」，以及可以把回答内容作为动态内容在流程中使用的说明。 ↩ ↩2 ↩3 ↩4

  3. Microsoft Learn, Microsoft Forms (Connector reference)。关于 Forms 连接器仅限组织账户使用、组表单不会显示在触发器列表中而需要手动输入表单编辑画面 URL 中「FormId=」之后的部分、以及触发器・操作一览的说明。 ↩ ↩2 ↩3

  4. Microsoft 支持, Choose who can fill out a form or quiz。关于公开范围 3 种(所有用户/仅限组织内/组织内特定用户)的区别、组织内限定时可以通过「记录姓名」记录回答者的姓名与邮箱地址、「每人限提交一条回答」也仅在组织内限定时才能设置、以及匿名表单不会记录回答者的说明。 ↩ ↩2 ↩3 ↩4 ↩5

  5. Microsoft 支持, Add questions that allow for file uploads in Microsoft Forms。关于文件上传问题仅在组织内限定(仅限组织内/组织内特定用户)的设置下才能使用、每个问题最多 10 个文件、单个文件的上限大小可以从 10MB・100MB・1GB 中选择、可以限制 Word/Excel/PowerPoint/PDF/图片/视频/音频的类型、以及文件会保存在 OneDrive for Business 的「应用 > Microsoft Forms」目录下的说明。 ↩ ↩2 ↩3 ↩4

  6. Microsoft 支持, Adjust your form or quiz settings in Microsoft Forms。关于表单设置中列举了接受回答(Accept responses)、开始・结束日期时间、每人限答一次、感谢消息自定义等内容的说明。 ↩ ↩2

  7. Microsoft 支持, Form, question, response, and character limits in Microsoft Forms。关于职场・学校账户的表单最多可以接收 5,000,000 条回答(GCC High/DoD 为 50,000 条)、每个表单 200 个问题・文本回答每题 4,000 字符・单次回答的文本回答合计上限 200,000 字符、以及超过 50,000 条后概要图表・单条回答查看・打印等功能会失效、只能使用 CSV 导出的说明。 ↩ ↩2

  8. Microsoft Learn, Troubleshoot known issues with forms in flows。关于单行文本中输入超过 255 个字符时流程可能无法正常运行、应该改用多行文本，审批操作的邮件附件上限为 5MB、超出后审批人需要在门户中查看，以及为负责人离职做准备的表单所有权移交的说明。 ↩ ↩2 ↩3

  9. Microsoft 支持, Use branching logic in Microsoft Forms。关于根据回答切换要显示的问题・分节的分支设置方法，以及分支目标只能指定后面的问题的说明。 ↩

  10. Microsoft Learn, Common ways to use a form in a flow。关于 Forms 一侧拥有面向表单所有者的通知与面向回答者的确认邮件设置、用动态内容「Responders’ Email」向回答者发送邮件的流程、插入回答内容的审批模板、转记到 Excel、以及把上传文件的回答通过解析 JSON 分解、用 first(body(‘Parse_JSON’))?[‘id’] 定位文件并创建共享链接的步骤说明。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  11. Microsoft Learn, Set up Microsoft Forms。关于组织外用户会以匿名方式提交回答、账户从租户中删除后相关数据会在 30 天后被删除、以及回答接近上限时导出到 Excel 后清空回答的说明。 ↩ ↩2 ↩3

  12. Microsoft Learn, Create approval flows with attachments。关于在给审批请求附加文件时，需要指定附件的名称与经过二进制编码的文件内容的说明。 ↩

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

Microsoft Forms 的文件上传问题，组织外的人也能使用吗？
不能。文件上传问题只有在把表单的公开范围设为「仅限本组织内的用户回答」(或组织内的特定用户)时才能添加，在允许组织外用户回答的设置下，这个问题本身就无法使用。上传的文件会保存到组织的 OneDrive for Business 中，单个问题最多可以接收 10 个文件，每个文件的上限可以从 10MB・100MB・1GB 中选择。如果需要从组织外接收附件，可以并用 OneDrive/SharePoint 的文件请求功能，或考虑开发 Web 表单。
Microsoft Forms 的表单最多能接收多少条回答？
职场或学校账户的表单最多可以接收 5,000,000 条回答(GCC High/DoD 环境为 50,000 条)。在社内的申请・请求受理场景中，几乎不会遇到这个上限本身带来的困扰，但一旦超过 50,000 条，概要图表的显示与单条回答的查看等功能就会失效，只能通过 CSV 导出来获取数据。此外，由于回答列表没有状态管理功能，不论件数多少，把受理的请求通过 Power Automate 转记到 SharePoint 列表并作为台账管理，都是标准做法。
能自动记录表单回答者是谁吗？
只要把公开范围设为组织内限定，就能记录。将其设为「仅限本组织内的用户回答」并启用「记录姓名」后，回答者的姓名和邮箱地址会与回答一起自动记录下来，不必再让对方特意填写姓名和所属部门。「每人限答一次」这个选项也只有在组织内限定时才能使用。反之，如果设为「所有用户均可回答」，回答就会变成匿名，无法记录是谁提交的。社内申请・请求的受理入口，原则上应采用组织内限定。
申请的受理入口，应该用 Forms 还是 SharePoint 列表来做？
如果优先考虑填写者的便利性，用 Forms；如果优先考虑台账管理，用 SharePoint 列表。Forms 便于从手机填写，问题分支和必填设置也很简单，但存在提交后无法编辑・无法确认进度、回答列表的管理功能也较弱等受理管理方面的短板。实务中采用「用 Forms 受理，再通过 Power Automate 转记到 SharePoint 列表」的结构，可以同时兼顾填写的便利性与台账管理。如果是列较多的定型申请，且所有填写者都熟悉列表操作，那么直接用列表的表单受理也是一个选项。

作者简介

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

Go Komura

小村软件有限公司 代表

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

联系我们
返回博客列表