consumer-goods-tpe-datakit-deploy

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

TPE Data Kit Deploy

TPE数据套件部署

Deploys the TPM Accruals Data Kit and its DMO mappings into a Salesforce org. Standalone and self-contained — runs on its own, or as a delegated step invoked by

consumer-goods-tpe-dashboard-configure

(Step 7), which passes through its own already-collected username and dry-run flag rather than this skill re-deriving them.

将TPM应计数据套件及其DMO映射部署到Salesforce组织中。独立且自包含——可自行运行，或作为由

consumer-goods-tpe-dashboard-configure

（步骤7）调用的委托步骤运行，该步骤会传递其已收集的用户名和试运行标志，而无需此技能重新获取这些信息。

Inputs to collect first

需提前收集的输入信息

Ask before starting, unless already supplied by a calling skill. Do not guess.

TPM System Admin username — already authenticated via
```
sf
```
CLI. Verify via the sibling script, never
```
sf org display --json
```
directly — that command's raw output includes
```
accessToken
```
(a live credential), which this script strips before printing:
bash
```
node ./scripts/sf-rest.js org-status --target-org <username>
```
Prints
```
{"username","alias","connectedStatus","orgId"}
```
. Non-zero exit or
```
connectedStatus != "Connected"
```
⇒ stop, ask the user to log in themselves.
Dry-run? — offer by default. In dry-run, Phase 1 (preflight) and Phase 2's read/diff steps still run; Phase 2's
```
FieldPermissions
```
writes and Phases 3-5 (deploy) are skipped and recorded as
```
pending — not run (dry-run)
```
.
TPM Data Connector installed and active — cannot be verified programmatically. Ask the user, spelling out the exact navigation steps rather than just naming the setting: "Can you confirm the TPM Data Connector is Active? 1) Go to Setup → Data Cloud Setup. 2) In the left nav, under EXTERNAL INTEGRATIONS, click Other Connectors. 3) Find 'TPM Data Connector' in the list and check its status." Wait for an explicit yes. If missing or inactive, stop — tell the user we cannot proceed without the TPM Data Connector being active, and explain the two different paths depending on org type:
- Production orgs — it's typically auto-installed within ~24h of Processing Service pairing, provided the org has a Data Cloud license. If both prerequisites are met, ask the user to wait and retry; if either isn't met (no pairing yet, or no Data Cloud license), that's the real blocker to resolve first.
- Sandbox orgs — auto-install commonly does not happen; it typically needs to be activated manually under EXTERNAL INTEGRATIONS → Other Connectors. Tell the user this is expected in sandboxes and ask them to activate it there, then confirm before continuing. Re-run this check once the user confirms it's Active.
Salesforce CRM Home org connection — cannot be verified programmatically. Ask the user, spelling out the exact navigation steps: "Can you confirm the Salesforce CRM Home org connection is Active? 1) Go to Setup → Data Cloud Setup. 2) In the left nav, under SALESFORCE INTEGRATIONS, click Salesforce CRM. 3) Check that the Home org connection status is Active." Wait for an explicit yes. If missing/inactive, stop — tell the user we cannot proceed without this connection being active (Phase 2's field-permission grants require the
```
Data Cloud Salesforce Connector
```
permission set, which won't exist until this connection is configured) — ask them to activate/configure it first, then re-run this check.
Permission set(s) for the TPM Admin persona + GenieAdmin permission set confirmed assigned — when invoked as a delegated step from
```
consumer-goods-tpe-dashboard-configure
```
, it passes through both results already confirmed in its own earlier phases; reuse them, don't re-ask or re-query. When invoked standalone, confirm each directly:
- Permission set(s) for the TPM Admin persona — "TPM Admin persona" is a role, not an actual permission set name; the org-specific permission set backing that persona (name/assignment) cannot be verified programmatically. Ask the user to confirm: "Is the permission set(s) required for the TPM Admin persona assigned to <username>?" Wait for an explicit yes.
- GenieAdmin — resolve its Label first (never show the API
```
Name
```
  to the user), then check the assignment:
  bash
```
sf data query --target-org <username> --query "SELECT Label FROM PermissionSet WHERE Name = 'GenieAdmin'"
sf data query --target-org <username> \
  --query "SELECT PermissionSet.Name FROM PermissionSetAssignment WHERE Assignee.Username = '<username>' AND PermissionSet.Name = 'GenieAdmin'"
```
  Missing ⇒ tell the user the Label from the first query (e.g. "User <username> is missing the <Label> permission set. Assign it now?") and ask permission to assign before continuing:
  bash
```
sf data create record --sobject PermissionSetAssignment \
  --values "AssigneeId=<userId> PermissionSetId=<psId>" --target-org <username>
```
  If declined, skip and note it in the report.
Namespace (
NS
) — when invoked as a delegated step,
```
consumer-goods-tpe-dashboard-configure
```
passes through its already-detected
```
NS
```
(raw namespace string); reuse it, don't re-detect. When invoked standalone, detect it once yourself, before Phase 1, with the sibling script:
bash
```
node ./scripts/detect-namespace.js --target-org <username>
```
Prints
```
{"NS","NS_SEGMENT","NS_APEX","NS_FIELD"}
```
as one line of JSON. Store all four and reuse everywhere below.

开始前询问，除非调用技能已提供相关信息。请勿猜测。

TPM系统管理员用户名——已通过
```
sf
```
CLI完成认证。通过同级脚本验证，切勿直接使用
```
sf org display --json
```
——该命令的原始输出包含
```
accessToken
```
（有效凭证），此脚本会在打印前将其移除：
bash
```
node ./scripts/sf-rest.js org-status --target-org <username>
```
输出
```
{"username","alias","connectedStatus","orgId"}
```
。若退出码非零或
```
connectedStatus != "Connected"
```
，则停止操作，要求用户自行登录。
试运行？——默认提供该选项。在试运行模式下，阶段1（预检）和阶段2的读取/差异步骤仍会运行；阶段2的
```
FieldPermissions
```
写入操作以及阶段3-5（部署）会被跳过，并记录为
```
pending — not run (dry-run)
```
。
TPM数据连接器已安装并激活——无法通过程序验证。请询问用户，并明确说明导航步骤，而非仅提及设置名称：*“能否确认TPM数据连接器处于激活状态？1) 进入Setup → Data Cloud Setup。2) 在左侧导航栏的EXTERNAL INTEGRATIONS下，点击Other Connectors。3) 在列表中找到'TPM Data Connector'并检查其状态。”*等待用户明确回复“是”。若缺失或未激活，停止操作——告知用户必须激活TPM数据连接器才能继续，并根据组织类型说明两种不同的解决路径：
- 生产组织——通常在Processing Service配对后约24小时内自动安装，前提是组织拥有Data Cloud许可证。若满足两个前提条件，请用户等待后重试；若任一条件不满足（尚未配对或无Data Cloud许可证），则需先解决该核心障碍。
- 沙箱组织——通常不会自动安装；需手动在EXTERNAL INTEGRATIONS → Other Connectors下激活。告知用户这是沙箱中的正常情况，请用户在此处激活后再确认继续。用户确认激活后，重新运行此检查。
Salesforce CRM主组织连接——无法通过程序验证。请询问用户，并明确说明导航步骤：*“能否确认Salesforce CRM主组织连接处于激活状态？1) 进入Setup → Data Cloud Setup。2) 在左侧导航栏的SALESFORCE INTEGRATIONS下，点击Salesforce CRM。3) 检查主组织连接状态是否为Active。”*等待用户明确回复“是”。若缺失或未激活，停止操作——告知用户必须激活此连接才能继续（阶段2的字段权限授予需要
```
Data Cloud Salesforce Connector
```
权限集，该权限集仅在配置此连接后才会存在）——请用户先激活/配置该连接，然后重新运行此检查。
已为TPM管理员角色分配所需权限集 + 已确认分配GenieAdmin权限集——当作为
```
consumer-goods-tpe-dashboard-configure
```
的委托步骤调用时，该步骤会传递其前期阶段已确认的两个结果；请复用这些结果，无需重新询问或查询。当独立调用时，直接确认以下内容：
- TPM管理员角色所需的权限集——“TPM管理员角色”是一个角色，而非实际的权限集名称；无法通过程序验证组织中支持该角色的特定权限集（名称/分配情况）。请询问用户确认：*“是否已为<username>分配TPM管理员角色所需的权限集？”*等待用户明确回复“是”。
- GenieAdmin——先解析其Label（切勿向用户显示API
```
Name
```
  ），然后检查分配情况：
  bash
```
sf data query --target-org <username> --query "SELECT Label FROM PermissionSet WHERE Name = 'GenieAdmin'"
sf data query --target-org <username> \
  --query "SELECT PermissionSet.Name FROM PermissionSetAssignment WHERE Assignee.Username = '<username>' AND PermissionSet.Name = 'GenieAdmin'"
```
  若缺失，则告知用户第一个查询得到的Label（例如：“用户<username>缺少<Label>权限集。是否现在分配？”），并在继续前请求用户许可：
  bash
```
sf data create record --sobject PermissionSetAssignment \
  --values "AssigneeId=<userId> PermissionSetId=<psId>" --target-org <username>
```
  若用户拒绝，则跳过并在报告中注明。
命名空间（NS）——当作为委托步骤调用时，
```
consumer-goods-tpe-dashboard-configure
```
会传递其已检测到的
```
NS
```
（原始命名空间字符串）；请复用该值，无需重新检测。当独立调用时，在阶段1前通过同级脚本自行检测一次：
bash
```
node ./scripts/detect-namespace.js --target-org <username>
```
输出一行JSON格式的
```
{"NS","NS_SEGMENT","NS_APEX","NS_FIELD"}
```
。存储这四个值并在后续步骤中复用。

Phase 1 — Preflight

阶段1 — 预检

Baseline for later verification — capture the latest

DataKitDeploymentLog

Id now, before any deploy work, to avoid a

CreatedDate

clock-skew false-negative in Phase 5:

bash

sf data query --target-org <username> \
  --query "SELECT Id FROM DataKitDeploymentLog ORDER BY CreatedDate DESC LIMIT 1" --json

Store as

LAST_ID_BEFORE_DEPLOY

(empty if zero rows).

Download & unzip
CGCloudAddons
— this skill fetches it itself rather than asking the user to do it manually.
bash
```
node ./scripts/download-static-resource.js \
  --target-org <username> --name CGCloudAddons
```
Capture
```
STATIC_RESOURCE_PATH=<dir>
```
from stdout as
```
<addons_root>
```
— every path below is relative to it (e.g.
```
<addons_root>/TPM/Accruals/TPM Accruals Data Kit
```
). Zero
```
StaticResource
```
rows ⇒ block: the package version installed in this org doesn't ship
```
CGCloudAddons
```
. Any other script failure ⇒ block and relay its stderr verbatim.

后续验证的基准——在开始任何部署工作前，捕获最新的

DataKitDeploymentLog

Id，以避免阶段5中因

CreatedDate

时钟偏差导致的误判：

bash

sf data query --target-org <username> \
  --query "SELECT Id FROM DataKitDeploymentLog ORDER BY CreatedDate DESC LIMIT 1" --json

将其存储为

LAST_ID_BEFORE_DEPLOY

（若无结果则为空）。

下载并解压
CGCloudAddons
——此技能会自行获取该资源，无需用户手动操作。
bash
```
node ./scripts/download-static-resource.js \
  --target-org <username> --name CGCloudAddons
```
从标准输出中捕获
```
STATIC_RESOURCE_PATH=<dir>
```
作为
```
<addons_root>
```
——以下所有路径均相对于此目录（例如：
```
<addons_root>/TPM/Accruals/TPM Accruals Data Kit
```
）。若
```
StaticResource
```
无结果，阻止操作：此组织中安装的包版本未附带
```
CGCloudAddons
```
。若脚本出现其他故障，阻止操作并直接转发其标准错误输出。

Phase 2 — Field permissions for CRM streams (derived from the downloaded package)

阶段2 — CRM流的字段权限（从下载的包中导出）

Two sibling scripts drive this phase — never hand-roll the parsing or the grant calls; see each script's own docstring for exactly what it does and why:

Extract the

{sobject, fields[]}

list from the downloaded package (read-only, always safe to run):

bash

node ./scripts/extract-crm-field-permissions.js \
  --dir "<addons_root>/TPM/Accruals/TPM Accruals Data Kit/force-app/main/default/dataSourceObjects" \
  > /tmp/crm-field-permissions.json

Zero entries in the output ⇒ block and report — shouldn't happen if Phase 1 succeeded.

Get the diff to update, silently (the script's own
```
--dry-run
```
— read-only: permission set,
```
sobject/describe
```
, existing
```
FieldPermissions
```
/
```
ObjectPermissions
```
rows) — don't show the user anything yet, this is just to find out whether there's anything to do:
bash
```
node ./scripts/update-field-permissions.js \
  --target-org <username> --input /tmp/crm-field-permissions.json --dry-run
```
```
{"error":"permission_set_not_found",...}
```
⇒ stop this phase, mark it blocked, and tell the user: "Could not find the 'Data Cloud Salesforce Connector' permission set — a likely explanation is that Salesforce CRM hasn't been configured yet (Setup → Data Cloud → Salesforce CRM). Please configure that first, then re-run this phase."
Only if
wouldGrant
or
objectWouldGrant
is non-empty, show the user exactly that diff (not the full extracted list) and get an explicit go-ahead before writing anything. If both are empty, everything's already granted — skip straight to step 5, no confirmation needed.
On confirmation, run it for real — add-only at both field and object level (see script docstring for exact semantics):
bash
```
node ./scripts/update-field-permissions.js \
  --target-org <username> --input /tmp/crm-field-permissions.json
```
Exit code
```
3
```
(or a non-empty
```
failed[]
```
/
```
objectFailed[]
```
) ⇒ don't guess a workaround — prompt the user to do it manually via Setup → Permission Sets → Data Cloud Salesforce Connector → Object Settings, using exactly the
```
failed[]
```
/
```
objectFailed[]
```
list, and note each in the report.
Record pass/blocked/pending, and the touched-field/object outcome (
```
granted
```
/
```
alreadyGranted
```
/
```
notFlsEligible
```
/
```
failed
```
,
```
objectGranted
```
/
```
objectAlreadyGranted
```
/
```
objectFailed
```
), for the final report. Dry-run mode (never proceed to step 4 when in dry run mode as it updates permissions, step1 and step2 can be run as they are read only)
```
objectGranted
```
/
```
objectAlreadyGranted
```
entries with
```
permissionsViewAllRecords: false
```
are expected for a small, fixed set of sobjects (currently just Product2) whose license blocks that flag — this is a known platform restriction the script applies silently; don't flag it to the user or treat it as something needing manual Setup action.

此阶段由两个同级脚本驱动——切勿手动编写解析或授权调用代码；请查看每个脚本的文档字符串以了解其具体功能和原因：

从下载的包中提取
{sobject, fields[]}
列表（只读，运行始终安全）：

bash

node ./scripts/extract-crm-field-permissions.js \
  --dir "<addons_root>/TPM/Accruals/TPM Accruals Data Kit/force-app/main/default/dataSourceObjects" \
  > /tmp/crm-field-permissions.json

若输出为空，阻止操作并报告——若阶段1成功则不应出现此情况。

静默获取需更新的差异（脚本自身的
```
--dry-run
```
——只读：权限集、
```
sobject/describe
```
、现有
```
FieldPermissions
```
/
```
ObjectPermissions
```
记录）——暂不向用户显示任何内容，仅用于确定是否有需要执行的操作：
bash
```
node ./scripts/update-field-permissions.js \
  --target-org <username> --input /tmp/crm-field-permissions.json --dry-run
```
若返回
```
{"error":"permission_set_not_found",...}
```
，则停止此阶段，标记为阻止状态，并告知用户：“未找到'Data Cloud Salesforce Connector'权限集——可能的原因是尚未配置Salesforce CRM（Setup → Data Cloud → Salesforce CRM）。请先配置该内容，然后重新运行此阶段。”
仅当
wouldGrant
或
objectWouldGrant
非空时，向用户显示确切的差异内容（而非完整的提取列表），并在执行写入操作前获取用户明确许可。若两者均为空，说明所有权限已授予——直接跳至步骤5，无需确认。
获得确认后，实际运行脚本——仅在字段和对象级别添加权限（请查看脚本文档字符串了解确切语义）：
bash
```
node ./scripts/update-field-permissions.js \
  --target-org <username> --input /tmp/crm-field-permissions.json
```
若退出码为
```
3
```
（或
```
failed[]
```
/
```
objectFailed[]
```
非空），切勿尝试变通方案——提示用户通过Setup → Permission Sets → Data Cloud Salesforce Connector → Object Settings手动授予权限，并使用
```
failed[]
```
/
```
objectFailed[]
```
列表作为参考，同时在报告中注明每一项。
记录通过/阻止/待处理状态，以及字段/对象的操作结果（
```
granted
```
/
```
alreadyGranted
```
/
```
notFlsEligible
```
/
```
failed
```
，
```
objectGranted
```
/
```
objectAlreadyGranted
```
/
```
objectFailed
```
），用于最终报告。试运行模式下（由于步骤4会更新权限，因此试运行模式下切勿执行步骤4，步骤1和步骤2为只读操作，可正常运行）
对于一小部分固定的sobject（目前仅为Product2），其
```
objectGranted
```
/
```
objectAlreadyGranted
```
条目中的
```
permissionsViewAllRecords: false
```
是预期情况，因为许可证会阻止该标志——这是已知的平台限制，脚本会自动处理，无需向用户标记或视为需要手动在Setup中操作的问题。

Phase 3 — Prepare and deploy data kit metadata

阶段3 — 准备并部署数据套件元数据

In
```
<addons_root>/TPM/Accruals/TPM Accruals Data Kit
```
, find-and-replace every instance of the placeholder
```
__SF_ORG_ID__
```
with the org's 15-digit Id. Get the org Id via the following sibling script
bash
```
node ./scripts/sf-rest.js org-status --target-org <username>
```
Take the
```
orgId
```
field from the printed JSON and truncate it to 15 chars (this call is cheap and idempotent — always re-run it here rather than relying on the Inputs step 1 result still being in context).

Deploy from that folder:

bash

sf project deploy start --target-org <username>

在
```
<addons_root>/TPM/Accruals/TPM Accruals Data Kit
```
中，将所有占位符
```
__SF_ORG_ID__
```
替换为组织的15位Id。通过以下同级脚本获取组织Id：
bash
```
node ./scripts/sf-rest.js org-status --target-org <username>
```
从输出的JSON中获取
```
orgId
```
字段并截断为15位字符（此调用成本低且幂等——请始终在此处重新运行，而非依赖步骤1输入结果仍在上下文中）。

从该文件夹部署：

bash

sf project deploy start --target-org <username>

Phase 4 — Deploy DMO mappings and run the deployment script

阶段4 — 部署DMO映射并运行部署脚本

DMO mappings — maps the data kit's DLOs to Data 360 DMOs. From

<addons_root>/TPM/Accruals/DmoMappings

bash

sf project deploy start --target-org <username>

Deployment script — from
```
<addons_root>/TPM/Accruals/Accruals Data Kit Deployment Scripts
```
:
bash
```
SF_ORG_ALIAS=<username> node deploy-tpm-tpe.js
```
This script POSTs to
```
/services/data/v67.0/actions/custom/flow/sfdatakit__DeployDataKitComponents
```
and returns an async Flow interview guid immediately; that response alone doesn't mean success — always confirm via the
```
DataKitDeploymentLog
```
check in Phase 5. This script runs from inside the downloaded/unzipped static resource.

DMO映射——将数据套件的DLO映射到Data 360 DMO。从

<addons_root>/TPM/Accruals/DmoMappings

执行：

bash

sf project deploy start --target-org <username>

部署脚本——从
```
<addons_root>/TPM/Accruals/Accruals Data Kit Deployment Scripts
```
执行：
bash
```
SF_ORG_ALIAS=<username> node deploy-tpm-tpe.js
```
此脚本会向
```
/services/data/v67.0/actions/custom/flow/sfdatakit__DeployDataKitComponents
```
发送POST请求，并立即返回异步Flow会话guid；该响应本身不代表成功——必须通过阶段5中的
```
DataKitDeploymentLog
```
检查进行确认。此脚本在下载并解压的静态资源内部运行。

Phase 5 — Verify

阶段5 — 验证

bash

sf data query --target-org <username> \
  --query "SELECT Id, DeploymentStatus, ComponentName, DeploymentError, CreatedDate FROM DataKitDeploymentLog WHERE Id > '<LAST_ID_BEFORE_DEPLOY>' ORDER BY CreatedDate DESC"

Every row for this run must have

DeploymentStatus = 'Successful'

and a blank

DeploymentError

. Never claim success while any row is
Failure
or has a non-empty error.

Alternative UI check: Data Cloud Setup → Data Kits → TPM Accruals → Local Deployment History → status

Successful

bash

sf data query --target-org <username> \
  --query "SELECT Id, DeploymentStatus, ComponentName, DeploymentError, CreatedDate FROM DataKitDeploymentLog WHERE Id > '<LAST_ID_BEFORE_DEPLOY>' ORDER BY CreatedDate DESC"

本次运行的每一行记录必须满足

DeploymentStatus = 'Successful'

且

DeploymentError

为空。只要有任何一行记录为
Failure
或包含非空错误信息，切勿宣称部署成功。

替代UI检查方式：Data Cloud Setup → Data Kits → TPM Accruals → Local Deployment History → 状态为

Successful

。

Known gotchas

已知问题

```
FlowDefinition
```
is not SOQL-queryable — don't probe it for readiness.
An
```
sfdatakit__DeployDataKitComponents
```
ApexClass probe can return 0 rows even when the framework is live — prefer probing
```
DataKitDeploymentLog
```
directly (Phase 5), never the Apex class.

```
FlowDefinition
```
无法通过SOQL查询——请勿通过它检查就绪状态。
即使框架已激活，
```
sfdatakit__DeployDataKitComponents
```
ApexClass查询也可能返回0条记录——请优先直接检查
```
DataKitDeploymentLog
```
（阶段5），切勿检查Apex类。

Rules

规则

Never claim success while any
```
DataKitDeploymentLog
```
row for this run is
```
Failure
```
or has a non-empty
```
DeploymentError
```
.
Only ever read the
```
CGCloudAddons
```
```
StaticResource
```
(via
```
download-static-resource.js
```
) — never deploy or modify it; the org's own
```
sf
```
-authenticated access token drives the download, never a hardcoded credential.

Never probe

FlowDefinition

or the

sfdatakit__DeployDataKitComponents

Apex class for readiness — probe

DataKitDeploymentLog

instead.

Never consult the org-shipped
```
README.md
```
(or any other in-package documentation bundled inside
```
CGCloudAddons
```
) for deployment guidance — follow this skill's phases exactly as written. If a script name or path documented here doesn't match what's actually in the downloaded package, that's a bug in this skill to fix (update the skill itself), not a cue to switch to package docs at runtime.
If a script or folder is missing from the downloaded folder, do not guess or change the scripts. e.g.: never change the script
```
deploy-tpm-tpe.js
```
.
Never run
```
update-field-permissions.js
```
without
```
--dry-run
```
first. If its
```
wouldGrant
```
/
```
objectWouldGrant
```
come back non-empty, never run for real without showing the user that exact diff and getting an explicit go-ahead — same as any other write in this skill. If both are empty, no confirmation is needed; proceed straight to reporting.
```
update-field-permissions.js
```
only ever adds — a new
```
FieldPermissions
```
/
```
ObjectPermissions
```
row where none existed, or flipping an existing row's off flag (
```
PermissionsRead
```
, or
```
PermissionsViewAllRecords
```
at the object level) to
```
true
```
. Never call it in a way that deletes a row, weakens an existing grant, or touches
```
PermissionsCreate
```
/
```
Edit
```
/
```
Delete
```
/
```
ModifyAllRecords
```
.
Never guess a workaround when the
```
sfdc_a360_sfcrm_data_extract
```
("Data Cloud Salesforce Connector") permission set is missing or a field/object ends up in
```
update-field-permissions.js
```
's
```
failed[]
```
/
```
objectFailed[]
```
— stop and prompt the user to grant field-level or object-level security manually via Setup (see Phase 2).

只要本次运行的任何
```
DataKitDeploymentLog
```
记录为
```
Failure
```
或包含非空错误信息，切勿宣称部署成功。
仅读取
```
CGCloudAddons
```
```
StaticResource
```
（通过
```
download-static-resource.js
```
）——切勿部署或修改它；组织自身的
```
sf
```
认证访问令牌会驱动下载操作，切勿使用硬编码凭证。
请勿通过
```
FlowDefinition
```
或
```
sfdatakit__DeployDataKitComponents
```
ApexClass检查就绪状态——请改用
```
DataKitDeploymentLog
```
进行检查。
切勿参考组织附带的
```
README.md
```
（或
```
CGCloudAddons
```
中捆绑的任何其他包内文档）获取部署指导——严格按照此技能的阶段说明执行。若此处记录的脚本名称或路径与下载包中的实际内容不匹配，说明此技能存在bug（需更新技能本身），而非在运行时切换到包文档的提示。
若下载文件夹中缺少脚本或文件夹，请勿猜测或修改脚本。例如：切勿修改
```
deploy-tpm-tpe.js
```
脚本。
运行
```
update-field-permissions.js
```
前必须先使用
```
--dry-run
```
。若其
```
wouldGrant
```
/
```
objectWouldGrant
```
返回非空结果，在实际运行前必须向用户显示确切的差异内容并获取明确许可——与本技能中的其他写入操作要求一致。若两者均为空，则无需确认，直接进入报告环节。
```
update-field-permissions.js
```
仅执行添加操作——在不存在
```
FieldPermissions
```
/
```
ObjectPermissions
```
记录时添加新记录，或将现有记录的关闭标志（
```
PermissionsRead
```
，或对象级别的
```
PermissionsViewAllRecords
```
）切换为
```
true
```
。切勿以删除记录、削弱现有授权或修改
```
PermissionsCreate
```
/
```
Edit
```
/
```
Delete
```
/
```
ModifyAllRecords
```
的方式调用该脚本。
当
```
sfdc_a360_sfcrm_data_extract
```
（“Data Cloud Salesforce Connector”）权限集缺失，或字段/对象出现在
```
update-field-permissions.js
```
的
```
failed[]
```
/
```
objectFailed[]
```
中时，切勿尝试变通方案——停止操作并提示用户通过Setup手动授予字段级或对象级安全权限（见阶段2）。

Report

报告

Produce a final report (pass/blocked/pending) covering: CRM stream field permissions (per-object field list from

extract-crm-field-permissions.js

, and each field's

granted

alreadyGranted

notFlsEligible

failed

outcome from

update-field-permissions.js

— flag any

notFlsEligible

entry with

onObject: false

separately, since that's a package/org data mismatch, not a normal skip), CRM stream object-level permissions (each sobject's

objectGranted

objectAlreadyGranted

objectFailed

outcome from the same script — a

permissionsViewAllRecords: false

on Product2 specifically is expected and not worth calling out), preflight (connector status), metadata deploy, DMO mapping deploy, deployment script run, and the

DataKitDeploymentLog

verification result (row count, any failures). This is exactly what

consumer-goods-tpe-dashboard-configure

Step 7 relays as its own result when this skill is invoked via delegation.

When invoked via delegation (the calling skill used the

Skill

tool to reach this file, rather than the user directly): this report is an intermediate result, not the end of the task. Return it to the calling skill and let it continue with its own next phase — do not present this report to the user as the final answer and stop. Only surface this report directly to the user when this skill was invoked standalone.

生成最终报告（通过/阻止/待处理），涵盖以下内容：CRM流字段权限（来自

extract-crm-field-permissions.js

的按对象划分的字段列表，以及来自

update-field-permissions.js

的每个字段的

granted

alreadyGranted

notFlsEligible

failed

结果——单独标记任何

onObject: false

的

notFlsEligible

条目，因为这是包/组织数据不匹配问题，而非正常跳过），CRM流对象级权限（来自同一脚本的每个sobject的

objectGranted

objectAlreadyGranted

objectFailed

结果——Product2的

permissionsViewAllRecords: false

是预期情况，无需特别指出），预检（连接器状态），元数据部署，DMO映射部署，部署脚本运行，以及

DataKitDeploymentLog

验证结果（记录数、任何失败情况）。当此技能通过委托调用时，此报告正是

consumer-goods-tpe-dashboard-configure

步骤7作为自身结果转发的内容。

当通过委托调用时（调用技能使用

Skill

工具访问此文件，而非用户直接调用）：此报告为中间结果，并非任务终点。请将其返回给调用技能，让其继续执行自身的下一阶段——切勿将此报告作为最终答案呈现给用户并停止操作。仅当此技能被独立调用时，才直接向用户展示此报告。