Power Apps 表列表中的两个「Custom」：Managed Solution 导入后，自定义表为什么从 Custom 页签消失？
Copyright Notice: This article is an original work licensed under the CC 4.0 BY-NC-ND license.
If you wish to repost this article, please include the original source link and this copyright notice.
Source link: https://v2know.com/article/1381
在 Power Apps / Dataverse 做 ALM 时，可能会遇到一个很容易让人误判的问题：
开发环境里明明是自己创建的业务表，也明确显示为「カスタム」，但把 unmanaged solution 导出成 managed solution，再导入测试环境之后，进入 Tables（表）→「カスタム」页签，表竟然全部消失了。
更奇怪的是，切换到「すべて（All）」之后，用业务表前缀搜索，它们又全部出现，而且右侧的「タグ」仍然显示「カスタム」。
那么，这些表到底还是不是自定义表？
答案是：是。表没有消失，也没有因为 Managed Solution 导入而变成微软内置表。真正变化的是 Power Apps 当前表列表页面的筛选方式。
本文记录一次发生于 2026 年 9 月 14 日的实际排查。
现象：71 张表导入成功，但 Custom 页签为空
本次案例中，业务表在开发环境通过 unmanaged solution 开发，随后导出为 managed solution，并导入测试环境。
首先排除“表没有导进去”这一可能。
导入包中共有 71 张业务自定义表；导入日志中，这 71 张表全部显示「処理済み」，没有表组件的导入错误。随后直接检查测试环境中的 Dataverse 元数据，包内 71 张表也全部存在，缺失数量为 0。
这些表的元数据状态为：
IsCustomEntity = true
IsManaged = true
也就是说，它们同时满足：
这是自定义表，但当前组件来自 Managed Solution。
然而，测试环境的「カスタム」页签为空。只有切换到「すべて」，再搜索 xxx_ 业务前缀，才能找到全部 71 张表。
所以问题已经从“表有没有导入”缩小成了：
Power Apps 的「カスタム」页签到底在筛选什么？
微软当前的 Tables 文档将 Custom 页签描述为“显示自定义表”，All 则显示全部表，同时说明表列表还可以根据 Type、Managed、Tags 等属性进行过滤。文档本身并没有进一步说明这里观察到的“Managed 自定义表被 Custom 页签排除”的行为，因此不能仅凭这篇说明推出“Custom = unmanaged”。
两个都叫「カスタム」，实际却不是同一个判断
本次排查没有停留在截图，而是进一步检查了当时 Power Apps Maker Portal 页面实际加载的前端 JavaScript。
需要先说明证据边界：本文所述前端实现关系来自 2026-09-14 本次调查记录中已经核对的代码。本文写作时再次访问这些 CDN 文件，当前读取工具因为 application/x-javascript 内容类型限制，无法重新展开源码，因此这里不会声称“刚刚再次独立读取并验证了源码”。
调查记录显示，「カスタム」页签绑定的是：
groupByPivots.isCustom
表列表的数据转换过程中，则通过 customFilter 生成这个内部分类字段。
问题就在这里。
根据本次代码调查整理出的等价逻辑，可以简化理解为：
如果表不是 Managed：
归入 Custom 分组
如果表是 Managed：
归入 Standard 或 Managed 分组
不归入 Custom 分组
这不是微软源码原文，而是根据当时实际代码整理出的等价逻辑。
换句话说，在本次检查到的 Power Apps 门户版本、以及该表列表的候选数据范围内，顶部 「カスタム」页签实际更接近于筛选“非受管表”。
但右侧看到的：
タグ = カスタム
走的却是另一套判断。
调查记录显示，表对象自身的 isCustom 来自 msdyn_iscustom，用于判断这个表是否属于自定义表。
因此这里存在两个名字极其相似、实际意义不同的东西：
groupByPivots.isCustom 是页面内部的分组标志；
表对象的 isCustom 则是这个表是否属于自定义表的属性。
也正因为如此，一张表完全可能同时出现下面这种状态：
「タグ＝カスタム」，但不出现在「カスタム」页签。
相关调查代码位置：
门户数据映射代码：module 357，相关模块 42335、42341、42344
门户分类与标签代码：module 359，相关模块 42336、42337
「カスタマイズ済み」也不是 Custom 页签的条件
另一个非常容易混淆的字段是：
カスタマイズ済み（Customized）
调查记录显示，这一列来自 msdyn_hasactivecustomization，但没有参与上述 Custom 页签的分类判断。
微软对 Solution 对象的官方说明也很明确：
「Managed」表示该对象来自 Managed Solution；
「Customizable」表示这个组件是否允许继续定制；
「Customized」表示该对象本身是 unmanaged，或者一个 managed 对象上存在 unmanaged customization layer。
因此，本案例中两个环境出现下面的变化是合理的：
| 环境 / 状态 | マネージド | カスタマイズ済み | カスタマイズ可能 | タグ | 当前「カスタム」页签 |
|---|---|---|---|---|---|
| 开发环境 | いいえ | はい | はい | カスタム | 显示 |
| 测试环境，刚导入 Managed Solution | はい | いいえ | はい | カスタム | 不显示 |
进一步根据本次前端筛选代码，可以得到：
| マネージド | カスタマイズ済み | 当前「カスタム」页签 |
|---|---|---|
| いいえ | はい | 显示 |
| はい | いいえ | 不显示 |
| はい | はい | 仍不显示 |
前两行是本次环境中的实际观察结果。
第三行则是根据筛选代码推导出的结果：因为分类首先受 Managed 状态影响，而 msdyn_hasactivecustomization 没有参与这个 Custom 分组判断。本次没有为了验证第三行而故意在测试环境制造 unmanaged customization，因此应当把“实测”和“代码推导”区分开。
为什么 Managed Solution 导入后属性会变化？
这与 Power Platform 的 Solution Layer 有关。
微软推荐在开发环境使用 unmanaged solution 进行开发，再将其作为 managed solution 部署到测试、UAT 和生产等下游环境。开发时组件位于 unmanaged layer；导出为 managed 并导入另一环境后，则进入 managed layer。
Microsoft Learn：Managed and unmanaged solutions
因此，开发环境中的对象显示：
マネージド = いいえ
カスタマイズ済み = はい
而刚完成 Managed Solution 导入、又没有额外 unmanaged 定制的测试环境显示：
マネージド = はい
カスタマイズ済み = いいえ
是有依据的。
这里讨论的是组件定义、Solution Layer 和定制状态，不是表里的业务数据有没有被新增、修改或删除。
同样，「カスタマイズ可能＝はい」只说明 Managed Properties 允许对相应组件进行一定程度的定制，并不代表组件内部任何内容都可以无条件修改。微软也明确说明，Managed Properties 用于控制 managed solution 中组件是否能够继续被定制。
Microsoft Learn：Solutions in Power Apps
如果界面中还看到「種類＝Standard」，也不要把它理解成“微软标准内置表”。这里的 Standard 是表类型，与 Activity、Virtual、Elastic 等类型相区分；微软的表属性文档也说明，大多数普通表都使用 Standard 类型。
真正容易误导人的，是界面上两个「Custom」
这个案例最值得注意的地方，并不是 Managed Solution 本身有什么异常，而是 UI 中两个名字相同的「カスタム」采用了不同的分类标准。
一个表可以同时满足：
它确实是业务自定义表，所以タグ＝カスタム；
但因为它是 Managed，所以当前页面的「カスタム」页签不显示它。
从使用者角度看，这确实非常容易让人联想到“表是不是没导进去”“是不是变成系统表了”或者“IsCustomEntity 被改掉了”。
以本文作者的界面评价来看，如果当前筛选逻辑保持不变，把这个页签命名成 「アンマネージド / 非受管」，会比「カスタム」更贴近实际行为；另一种方案则是继续使用 Custom 这个名称，但让筛选逻辑与「タグ＝カスタム」所代表的自定义表属性保持一致。
不过，这只是对当前 UI 的评价和改进建议。
截至本次调查，没有找到微软针对这一命名选择的明确解释，因此不能据此推测它的内部历史原因，也不能声称微软故意误导用户，更不能写成“微软已经确认的 Bug”。
准确的结论只能是：
在 2026-09-14 本次检查到的 Power Apps 门户版本中，实际实现如此。
切换「すべて」并搜索 xxx_ 后，同一批 Managed 自定义表全部出现，标签仍为「カスタム」。
实际应该怎样查找 Managed Solution 导入的自定义表？
遇到这种情况，不要为了让表重新出现在 Custom 页签里而修改表，更没有必要人为制造 unmanaged customization layer，或者重新向测试环境导入 unmanaged solution。
正确做法很简单：
-
在 Tables →「すべて（All）」 中，通过
xxx_等业务 Publisher Prefix 搜索；也可以直接进入对应 Solution 查看其中包含的 Table。若仍然怀疑导入异常，再检查 Solution Import Log 与 Dataverse 元数据中的表定义。
只要表已经存在、IsCustomEntity = true，并且只是 IsManaged = true，那么它依然是业务自定义表。
Managed 改变的是组件的部署和分层状态，不会把一张自定义表“洗成”微软内置表。
而 Power Apps 表列表中的「Custom」页签与「Custom」标签，在当前版本里恰好没有使用同一套判断——这才是整个现象看起来如此反直觉的原因。
This article was last edited at