把 Excel 台账迁移到 SharePoint 列表 ── 用共享・历史记录・流程联动告别「台账损坏」

「打开『案件管理台账.xlsx』时发现是只读的。因为不知道是谁打开着，就复制了一份来更新，结果又搞不清楚哪个才是最新版」「排序之后行错位了，别的案件的备注被安到了另一件事上」。我们经常从用共享文件夹里的 Excel 运转案件管理・咨询管理・备品管理等台账的公司那里，收到这样的咨询。

Excel 作为电子表格软件很优秀，但作为「多人同时追加・更新的台账存放处」在结构上是勉强的。如果已经导入了 Microsoft 365，用于这种用途的专用容器 ── SharePoint 列表(Microsoft Lists) ── 其实已经在手边了。逐行同时编辑、变更历史、带类型的输入，乃至通过 Power Automate 发展到通知・审批，台账所需要的东西一应俱全。

本文将整理 Excel 台账的局限出现在哪里、迁移到 SharePoint 列表的判断标准与迁移步骤、以列表视图阈值 5,000 为首的设计注意事项，以及通过 Power Automate 联动把台账变成「会动的台账」的整个过程。

目标读者与前提环境：本文假定的读者是用共享文件夹的 Excel 台账、由多人共同运转业务的信息系统・业务负责人。前提是已经导入 Microsoft 365，并且是可以使用 SharePoint Online 的方案(SharePoint 列表=Microsoft Lists 就是这个范围内的功能)。¹ 本文涉及的 Power Automate 联动，包括 SharePoint 连接器在内也全部都是标准连接器，因此可以用 Microsoft 365 许可证所包含的 Power Automate 使用权来搭建。²³ 只有在触及第 7 章提到的 Dataverse 或 SQL 等高级连接器时，才需要追加许可证。⁴

1. 先说结论

• Excel 台账事故(覆盖・行错位・不清楚哪个是最新版)的根本原因，在于整个文件就是编辑单位这件事。SharePoint 列表以行(项目)为单位进行编辑与历史管理，因此这类事故在结构上就不容易发生。
• SharePoint 列表每个列表最多可以保存 3,000 万个项目，列表项目的附件每个文件最大为 250MB。⁵
• 经常被提起的「5,000 条限制」其实是「列表视图的阈值」，并不是可保存条数的上限。通过索引列与经过筛选的视图设计，即使超过 5,000 条也可以继续运营。⁶⁷
• SharePoint Online 的列表从创建之初就启用了版本历史记录(默认 50 个版本)。「谁在什么时候修改了哪个项目」从一开始就会被保留下来。⁸
• Microsoft Lists 具备从 Excel 工作簿创建列表的导入功能。不过在导入之前，先完成取消单元格合并・整理成一行一条记录・清理表述不一致，并完成列类型的设计，这才是迁移的实务做法。¹
• SharePoint 连接器是标准连接器，因此可以在 Microsoft 365 的许可证范围内，以「项目已创建或已修改时」为起点，搭建通知・审批・催办的流程。²³
• 以汇总・分析为主要目的的工作表，以及只有 1～2 人触碰、更新频率很低的台账，继续保持 Excel 也没有问题。反过来，关联关系较多・条数达到数十万件规模・需要事务一致性的业务数据，属于Dataverse(面向 Power Platform 业务应用的数据基础设施。它把数据保存为表的集合，是以表间关联与基于角色的访问控制为前提设计的云数据库)⁹或业务系统(委托开发)的领域，而不是列表的领域。另外，从 Power Automate 使用 Dataverse 的连接器被归类为高级层，因此以追加许可证为前提。⁴

2. Excel 台账的局限出现在哪里

在接受咨询的过程中，Excel 台账开始崩坏的那些点，大体上是共通的。

• 同时编辑与覆盖。共享文件夹里的 Excel，只要有人打开着，就会变成只读。等不及的人会复制一份，于是「台账_最新.xlsx」「台账_0715_田中修改.xlsx」不断增殖，谁都搞不清楚哪一份才是正本。用浏览器版 Excel 的共同编辑功能可以避免同时打开本身这个问题，但接下来列举的问题依然存在。
• 行错位与破坏。在筛选状态下直接粘贴、排序时选错了范围、插入行时只有相邻的列错位了。电子表格的自由度，对台账而言同时也是破坏数据的自由。而且谁在什么时候弄坏的，能作为线索的顶多也就是文件的更新日期时间而已。
• 输入规则得不到遵守。即使规定了「状态从这 5 个里选」「日期格式为 yyyy/mm/dd」，单元格里也可以输入任何内容。即便设置了数据验证(数据的输入规则)，也很容易被复制粘贴覆盖掉。表述不一致，会在之后的汇总・检索环节以成本的形式反弹回来。
• 宏的个人依赖化。用 VBA 把转录和汇总自动化的台账，一旦制作者调岗或离职，就会变成一个黑箱。带宏的工作簿一旦文件损坏，损失往往也更大。
• 无法把「查看」与「编辑」分开。即使只是想让人查看，也不得不把可编辑的文件交出去，无法做到权限分离。

另一方面，也有一些台账继续保持 Excel 就好。更新者只有 1～2 人、频率也低的台账，每月制作后只是分发出去的汇总表，计算公式・数据透视表・图表才是主角的分析工作表，打印版式本身就承载着意义的表单。这些要么不会出现「多人同时更新」的问题，即使出现，Excel 的优势(计算・排版)也占上风。是否替换的判断标准，整理在第 7 章的表格中。

3. SharePoint 列表是什么 ── 不是单元格表格,而是「行数据库」

SharePoint 列表是 Microsoft 365 所包含的 SharePoint 功能，也可以从 Microsoft Lists 应用创建・使用同一个列表(在 SharePoint 中打开列表时会被引导至 Microsoft Lists，两者实体是同一个)。¹⁰ 与 Excel 最大的不同在于，编辑的单位不是单元格，而是行(项目)。

补充说明几个在实务中很有用的功能。

• 列的类型。使用选项列的话，状态就只能输入已定义好的值。用户列与组织账户绑定，因此「负责人」的表述不一致会消失。日期列只能作为日期输入，因此期限的判断与排序会变得确实可靠。还可以用引用(查找)列来引用其他列表的值，搭建简单的关联关系。¹¹¹²
• 视图。可以像「我负责的部分」「本月到期」「仅未完成」这样，把同一份数据以不同用途的呈现方式共享出去。用 Excel 复制工作表按人分发的做法就不再需要了。
• 版本历史记录。每个项目都会记录何时・谁・修改了哪一列・怎么改的，并且可以恢复到以前的版本。在 SharePoint Online 中，从列表创建时起就默认启用。⁸ 「是谁删掉的」「想知道之前的值」都能靠标准功能得到答案。
• 警报・规则。仅在列表这一侧就可以设置在值变更时发送通知的简易规则。¹ 复杂的通知或条件分支，就轮到 Power Automate 登场了(第 6 章)。
• Teams・移动端。Lists 可以作为标签添加到 Teams 频道中，能够从桌面端・Web・移动端操作同一个列表。¹ 从现场用手机更新咨询处理情况这类运营方式也变得现实可行。

4. 迁移实务 ── 清理→列设计→导入→视图→切换

从 Excel 台账的迁移，按以下顺序进行。比起工具操作本身，最初的两个步骤(清理和列设计)才是决定成败的关键。

(1) 先清理现有数据

Excel 台账里，一定混杂着因为是电子表格才被允许存在的结构。列表是「1 行=1 项目」的扁平结构，因此要先在 Excel 一侧整理好。

• 取消单元格合并(合并单元格无法带入列表)
• 整理成一行一条记录(消除一个单元格里塞了多个案件、或一条记录跨多行的情况)
• 把表头统一为一行(两段式表头要重新命名列名)
• 统一表述不一致(「处理中/處理中/在办」→统一为选项的候选值)
• 删除中途的小计行・用于装饰的空行
• 对于含公式的单元格，决定是「作为值保留」还是「迁移后在汇总一侧重新实现」

这项清理工作既是迁移作业，同时也是对台账设计的一次盘点。「这一列，其实没人在填」「这两列其实是同一个意思」这类发现大量出现，是很正常的。

(2) 列类型的设计

决定清理好的 Excel 各列，应该对应到哪种类型的列表列。常见套路如下。

(3) 导入

Microsoft Lists 具备读取 Excel 工作簿数据来创建列表的功能，可以把现有台账作为出发点。¹ 操作入口是在 Microsoft Lists 应用(或想要放置列表的 SharePoint 网站)中依次选择「新建」>「列表」，再从创建方式列表中选择「从 Excel」。指定清理好的工作簿之后，就会进入确认要导入的列及其类型的画面。

不过，在实务中不建议完全依赖导入的自动判断，而是建议先决定好列类型，导入时再进行确认(或者先设计好空列表，之后再把数据灌进去)。尤其是选项列・用户列是决定台账质量的列，如果就这样以文本列的状态开始运营，好不容易迁移过来的意义就会减半。

另外，对于超过数千行的台账，不要计划把所有数据一次性交给一次导入来完成。刚导入完成，第 5 章会讲到的 5,000 条阈值的设计就会立刻成为第一个课题，而且导入的数据量越大，列类型的确认与失败后的重做也会越沉重。更安全的做法是，先创建好列设计已经确定的空列表，准备好用于应对阈值的索引列与筛选视图，然后把数据分割成划分清楚的单位再逐批导入(先用一部分实际数据做一次彩排)。

(4) 视图与权限

默认视图设置成「仅未完成・按期限升序排列」这类符合日常业务形态的设置，全部数据的视图另外准备。这同时也是对后文提到的 5,000 条阈值的一种预先准备。权限方面，先从按列表单位区分「可以编辑的人」和「仅可查看的人」开始，项目单位的细粒度权限只在真正必要时才使用(条数增多之后再变更权限会受到限制。参见第 5 章)。

(5) 并行期间与切换

理想情况是定好迁移日、一次性切换，但现实中总会出现「暂时还在 Excel 上写」的人。如果要设置并行期间，安全的做法是明确宣布「正本是列表，Excel 只是用于参考的副本」，并把 Excel 一侧设为只读。如果放任双重运营持续下去，最终会导致两边都不再是正本。

5. 限制与设计注意事项 ── 5,000・附件・「Excel 有而列表没有的东西」

正确理解列表视图阈值 5,000

SharePoint Online 对单个视图(显示・排序・筛选・分组等操作)一次能处理的项目数，默认设有 5,000 条的阈值。一旦超过，就会出现「此列表的项目数超过了列表视图阈值」的错误，或者列的排序・筛选失败。⁶⁷

这里重要的是，这并不是可保存条数的上限。列表本身最多可以保存 3,000 万个项目。⁵ 受限制的是「一次扫描超过 5,000 条范围的查询」，而应对方法官方也有说明。

• 为用于筛选的列建立索引。为作为排序・筛选轴心的列(受理日期、状态、负责人等)创建列索引。不过索引的添加・删除有一个「只能在 2 万个项目以内进行」的限制，因此要在列表变大之前就完成设计。⁷
• 让视图始终把范围缩小到 5,000 条以内。像「本年度部分」「仅未完成」「负责人=本人」这样，把基于索引列的筛选纳入默认视图中。⁷

由于索引的创建位置不太容易找到，这里写下菜单路径。依次进入打开列表右上角的设置(齿轮)>「列表设置」(List settings)>「列」区块的「索引列」(Indexed columns)>「创建新索引」(Create a new index)，选择目标列(主列)后创建。每个列表/文档库最多能创建 20 个索引列，因此请把范围限定在经常用于筛选的列上。¹³

如果是中小企业的案件・咨询台账，一年通常是数百到数千条，短期内看起来与 5,000 条无缘，但只要积累几年，就会是能够触及到的数字。如果从一开始就准备好「按年度筛选的默认视图+索引列」，之后就不用慌张。另外，当项目数超过 10 万条时，还会出现无法在列表・文件夹单位上切断权限继承等其他限制，规模变大还有别的约束。⁵ 如果从一开始就能预见到数十万件规模的运营，那就应该选择数据库(Dataverse・SQL)而不是列表(第 7 章)。

附件的处理方式 ── 附件列还是文档库

列表的项目可以附加文件，单个文件最大支持 250MB。⁵ 不过在实务中，需要注意以下两点。

• 列表的版本历史记录会记录列的变更，但附件的变更不会被版本管理。⁸
• 从 Power Automate 操作附件时，SharePoint 连接器所能处理的附件文件大小上限为 90MB。²

像报价单・报告书这类本身就需要版本管理或共同编辑的文件，与其作为列表的附件，不如保存到文档库，再用链接或管理编号与列表关联，这样的结构更好处理。附件列则干脆定位为「一张传真扫描件」这种从属于项目的轻量证据用途。

Excel 有而列表没有的东西

在迁移咨询中，必定要确认的一点，是对「因为是 Excel 才能做到的事情」的依赖程度。

• 自由的排版。单元格合并、两段式表头、仅靠颜色区分来赋予意义的表格是无法重现的。要把「意义」转移到列上，把「呈现方式」转移到视图上。
• 单元格间复杂的计算公式。列表也有汇总列(计算值)，但无法替代引用整张工作表的复杂计算网络或数据透视表。汇总・分析这部分，改为让 Excel 或 Power BI 连接到列表的数据来完成，形成分工。从 Power BI Desktop 连接列表制作报表的步骤，以及在 Power BI 服务中直接从列表创建语义模型并定期更新的方法，官方都有提供。¹⁴¹⁵
• 打印版式。如果一直把台账原样当作打印表单使用，列表的画面是无法充当表单的。如果打印是需求，就需要把导出的数据灌入 Excel 模板，或者另外制作表单一侧等设计。

也就是说，「输入与共享交给列表，计算与排版交给 Excel/Power BI」，重新组织成这样的分工，才是替换的正确形态。

6. 通过 Power Automate 联动,让台账动起来

SharePoint 列表化最大的红利，是与 Power Automate 的联动。SharePoint 连接器是标准连接器，因此可以在能使用标准连接器的 Microsoft 365 许可证范围内搭建云端流程。² 列表准备了「项目已创建时」「项目已创建或已修改时」等触发器，可以直接把台账的登记・更新作为流程的起点。²³

flowchart TD
    Excel[现有的 Excel 台账] -- 清理・设计列后迁移 --> List[SharePoint 列表<br/>案件・咨询台账]
    Forms[Microsoft Forms<br/>申请・请求受理入口] -- 转录回复内容 --> List
    List -- 项目创建/更新触发器 --> Flow[Power Automate<br/>云端流程]
    Flow --> Notify[通过 Teams/邮件通知负责人]
    Flow --> Approve[转入审批流程]
    Sched[定时执行] --> Remind[对过期项目进行催办]
    List -.-> Sched
    List -- 连接/导出 --> BI[Excel 汇总・Power BI 报表]

有代表性的模式有三种。

• 通知。新的咨询被登记后，向负责的频道发送 Teams 通知；负责人列被设置后，给本人发邮件。台账的运营方式会从「要主动去看」变成「会主动通知我」。
• 审批。状态变为「审批请求」时启动审批流程，把结果与审批人・日期时间写回列表的列中。这种让审批凭证汇集到台账同一行的结构，在另一篇文章《用 Power Automate 搭建审批流程 ── 将纸质与邮件签核、申请电子化》中有详细说明。¹⁶
• 催办・盘点。每天早晨定时启动，提取「已过期且未完成」的项目，统一通知给负责人。使用 SharePoint 的提醒流程，作为经典场景，官方也有相关介绍。³ 包含营业日判断与月末处理在内的定期执行设计，整理在《用 Power Automate 设计定期执行流程 ── 月末处理・营业日判定・提醒的实务》中。

有一点设计上的注意事项。如果「项目已创建或已修改时」触发器的流程自己更新了列表，那次更新有可能又会再次启动自己，形成无限循环。不要靠后段的条件分支去丢弃，而是在触发器一侧用触发条件(trigger conditions)写明「仅在状态为特定值时才启动」，这才是标准做法。不满足条件的更新根本不会发生执行，也不会留在执行历史记录中。¹⁷

设置位置与表达式的形式是这样的。在设计器中选中触发器，在「设置」(Settings)的「触发条件」(Trigger conditions)里通过「+ 添加」逐行写入表达式(在经典设计器中则是触发器右上角的「…」>「设置」>「触发条件」)。表达式必须以@开头。写了多条时，只有全部满足才会启动，因此如果是「满足其中之一即可」的情况，要用@or(条件1, 条件2)合并成一条。¹⁷

@equals(triggerBody()?['Status']?['Value'], '审批请求')

这是「仅当状态列(内部名 Status)变为『审批请求』时才启动」这一条件。请注意，选项列的值需要深入到['Value']才能取出，而且列名用的不是画面上显示的名称，而是内部名(如果是单行文本列，则像@equals(triggerBody()?['Status'], '审批请求')这样，不需要['Value'])。如果对手写表达式没有把握，官方文档所介绍的做法 ── 先在流程中临时放置一个「筛选数组」(Filter array)操作，在画面上组好条件后，用「以详细模式编辑」把生成的表达式复制出来，粘贴到触发条件里，再删除该操作 ── 是可靠的做法。¹⁷

不过触发条件只有和流程自身的写回会让条件变为假这件事配对起来，才能真正止住循环。如果是「状态为『审批请求』时启动」的流程，那么设计就必须包含在处理的最后一定要把状态更新为『处理中』或『已审批』等别的值这一步。如果写回之后状态依然停留在『审批请求』，这次更新又会让条件再度成立，审批请求或通知就会反复飞出去。如果无论如何都需要一次不改变条件所用列的写回，请追加一个「已处理」标志列，并把它加入触发条件中。

如果想要进一步拓宽输入的入口，用 Microsoft Forms 接收、再由流程转录到列表的结构会很有效(参见《用 Microsoft Forms 搭建社内申请・请求的受理入口 ── 把邮件与口头请求汇总到表单》)。另外，本文范围内的内容全部都可以用标准连接器搭建，但一旦触及 Dataverse 或 SQL，就会进入高级许可证的领域。⁴ 这条边界线整理在《Power Automate 的许可证 ── Microsoft 365 里能免费到什么程度，什么时候需要 Premium》中。

7. 判断表 ── 维持 Excel/列表化/业务应用・数据库开发

大致的判断标准是：只要还能称之为「台账」，用列表就足够了；一旦开始让列表承担「业务系统的替代品」这个角色，就是危险信号。当引用列不断增加、多条流程相互纠缠、为应对阈值而设置的视图开始泛滥时，那就已经变成了应该靠数据库与业务应用来解决的问题。列表的好处，在于能够以几乎不需要额外费用的标准功能，安全地支撑起到达那个临界点之前的那几年。

8. 总结

共享文件夹里 Excel 台账的问题，不是负责人注意力的问题，而是结构上的问题。只要整个文件仍然是编辑单位，覆盖・行错位・不清楚哪个是最新版就会反复出现。迁移到 SharePoint 列表后，编辑会变成行单位，输入会带上类型，变更会留在版本历史记录中，权限也能按角色区分开来。

迁移的实务，比起导入操作本身，「数据清理」与「列类型设计」才是主体。理解 5,000 条阈值是视图的限制这一点，从一开始就准备好索引列与经过筛选的视图，就能长期放心使用。附件要与文档库确定好分工，计算和排版则交给 Excel/Power BI。做到这种分工的台账，会以 Power Automate 的触发器为起点，成长为通知・审批・催办都能自动运转的「会动的台账」。

而当列表开始变得吃力时，那就是该转向 Dataverse 或业务系统的信号。哪些交给标准功能来做，从哪里开始要靠开发来解决——从这条界线的划分开始的咨询，敝公司都可以承接。

相关文章

• 用 Power Automate 实现业务自动化 ── 云端流程与桌面流程的分工，以及错误处理设计
• 用 Power Automate 搭建审批流程 ── 将纸质与邮件签核、申请电子化
• 用 Microsoft Forms 搭建社内申请・请求的受理入口 ── 把邮件与口头请求汇总到表单
• 用 Power Automate 设计定期执行流程 ── 月末处理・营业日判定・提醒的实务
• Power Automate 的许可证 ── Microsoft 365 里能免费到什么程度，什么时候需要 Premium

相关咨询领域

合同会社小村软件承接从 Excel 台账的 SharePoint 列表化・Power Automate 联动设计咨询，到列表容纳不下的业务数据库・业务应用委托开发的全部业务。

• 技术咨询・设计评审
• Windows 应用开发
• 联系我们

参考链接

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

SharePoint 列表只能存放 5,000 条数据吗？

不是的。5,000 条是列表视图的阈值，是单个视图(显示・排序・筛选)一次能处理的项目数量的默认上限。列表本身最多可以保存 3,000 万个项目。如果要在超过 5,000 条的情况下继续使用，可以为用于筛选的列建立索引，并把默认视图设计成始终把范围缩小到 5,000 条以内(例如按本年度、按负责人筛选)，就能持续运营下去。索引的追加在项目数超过 2 万之后会受到限制，因此在列表变大之前先做好设计很重要。

可以直接用 Excel 文件创建 SharePoint 列表吗？

可以。Microsoft Lists 具备读取 Excel 工作簿数据来创建列表的功能，可以把现有台账作为起点。不过在此之前，需要先完成取消单元格合并、整理成一行一条记录、统一表头行、清理表述不一致等准备工作。此外，选项列・用户列・日期列这类列类型是列表价值的核心，因此建议不要完全依赖导入自动判断，先确定好列的设计再导入。

什么情况下 Excel 台账可以继续保持原样？

如果更新者只有 1～2 人、更新频率也很低，或者与其说是台账，不如说是用于汇总・分析的工作表，又或者复杂的计算公式・数据透视表・打印版式才是主要目的，这些情况下通常继续使用 Excel 也没有问题。反过来，如果是多人日常追加・更新、需要管理状态(处理中・已完成等)、希望追溯变更历史与负责人、想要与通知或审批联动的台账，则适合迁移到 SharePoint 列表。

做成 SharePoint 列表之后，用 Power Automate 能做什么？

由于 SharePoint 连接器属于标准连接器，因此在 Microsoft 365 许可证范围内，就可以从「项目已创建时」「项目已创建或已修改时」等触发器启动云端流程。典型的例子包括新登记项目的 Teams 通知、以状态变更为契机的审批流程、对过期项目的定期催办等。积累下来的数据还可以通过 Excel 或 Power BI 引用来进行汇总・报表化，因此台账可以成为通知・审批・汇总的枢纽。

作者简介

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

Go Komura

小村软件有限公司 代表

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