platform-custom-report-type-generate

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Specification

规范

Salesforce Custom Report Type Metadata Knowledge

Salesforce Custom Report Type元数据知识

Overview

概述

Custom Report Types (CRTs) define the data framework for Salesforce reports. They specify a primary object, up to 3 related objects, the relationship (join) between them, and which fields are available in the report builder.

Custom Report Types（CRTs）为Salesforce报表定义了数据框架。它们指定一个主对象、最多3个相关对象、对象间的关系（连接），以及报表构建器中可用的字段。

Purpose

用途

Enable reporting across custom objects and custom relationships not covered by standard report types
Curate a focused set of fields for report builders (including fields reached via lookup)
Control inner/outer join behavior to include or exclude primary records without related records

支持标准报表类型未覆盖的自定义对象和自定义关系的报表制作
为报表构建器整理一组聚焦的字段（包括通过查找关系获取的字段）
控制内/外连接行为，以包含或排除无相关记录的主对象记录

Configuration

配置

File extension:

.reportType-meta.xml

. The file basename is the report type's developer name (e.g.

AccountsWithProjects.reportType-meta.xml

). Each CRT is a single file, not nested under an object folder.

文件扩展名：

.reportType-meta.xml

。文件基名为报表类型的开发者名称（例如

AccountsWithProjects.reportType-meta.xml

）。每个CRT对应一个单独的文件，无需嵌套在对象文件夹下。

Key Elements

关键元素

Top-level

<ReportType>

children:

Element	Required	Notes
`<fullName>`	Yes	API identifier; must match the file name. Letters, numbers, underscores; must begin with a letter; no spaces; no trailing underscore; no consecutive underscores
`<label>`	Yes	Human-friendly name shown in the report type picker
`<description>`	Recommended	State the business "why" — who uses this and what they learn
`<baseObject>`	Yes	API name of the primary object (e.g. `Account` , `Project__c` ). Cannot be changed after initial creation. All objects, including custom and external, are supported (external objects from API 38.0+)
`<category>`	Recommended	Report builder category — see `references/category-values.md`
`<deployed>`	Yes	`true` to expose to users; `false` while building/iterating
`<join>`	Conditional	Adds a related object and its join behavior. Nest further `<join>` blocks for deeper relationships
`<sections>`	Recommended	Groups of columns available to the report type. Though not strictly required, a report without columns isn't useful

<sections>

(group of columns) sub-elements:

Element	Required	Notes
`<masterLabel>`	Yes	Section heading shown in the report builder
`<columns>`	Conditional	One per field exposed in the section

<columns>

(single field) sub-elements:

Element	Required	Notes
`<field>`	Yes	Field API name (or dotted lookup-traversal path)
`<table>`	Yes	The object the field belongs to — base object name or dotted relationship path
`<checkedByDefault>`	Yes	`true` if the column is selected by default in the report builder
`<displayNameOverride>`	No	Custom column label shown in the report builder, overriding the field's default label

顶级

<ReportType>

子元素：

元素	是否必填	说明
`<fullName>`	是	API标识符；必须与文件名匹配。可包含字母、数字、下划线；必须以字母开头；无空格；无末尾下划线；无连续下划线
`<label>`	是	在报表类型选择器中显示的友好名称
`<description>`	推荐	说明业务用途——谁使用它以及能获取什么信息
`<baseObject>`	是	主对象的API名称（例如 `Account` 、 `Project__c` ）。初始创建后无法修改。支持所有对象，包括自定义对象和外部对象（API 38.0+支持外部对象）
`<category>`	推荐	报表构建器类别——请查看 `references/category-values.md`
`<deployed>`	是	`true` 表示向用户暴露； `false` 表示处于构建/迭代阶段
`<join>`	可选	添加相关对象及其连接行为。可嵌套更多 `<join>` 块以实现更深层次的关系
`<sections>`	推荐	报表类型可用的列组。虽然并非严格必填，但没有列的报表毫无用处

<sections>

（列组）子元素：

元素	是否必填	说明
`<masterLabel>`	是	在报表构建器中显示的节标题
`<columns>`	可选	节中暴露的每个字段对应一个该元素

<columns>

（单个字段）子元素：

元素	是否必填	说明
`<field>`	是	字段API名称（或带点的查找遍历路径）
`<table>`	是	字段所属的对象——主对象名称或带点的关系路径
`<checkedByDefault>`	是	`true` 表示该列在报表构建器中默认被选中
`<displayNameOverride>`	否	在报表构建器中显示的自定义列标签，用于覆盖字段的默认标签

Critical Rules (Read First)

重要规则（请先阅读）

Rule 1: If

<fullName>

Is Present, It Must Match the File Name

规则1：如果包含

<fullName>

，必须与文件名匹配

In source format,

fullName

is inherited from

Metadata

and derived from the file name, so the

<fullName>

element is technically optional. The repo convention is to include it. If you include
<fullName>
, its value must equal the file name (everything before
.reportType-meta.xml
) exactly — same characters, same casing, same underscores.

Wrong — file name and

<fullName>

differ:

File:
```
account_projects.reportType-meta.xml
```

<fullName>AccountProjects</fullName>

(Mismatch: file uses

account_projects

, fullName uses

AccountProjects

)

Right — file name and

<fullName>

are identical:

File:
```
AccountProjects.reportType-meta.xml
```
```
<fullName>AccountProjects</fullName>
```

在源格式中，

fullName

继承自

Metadata

并由文件名派生，因此

<fullName>

元素在技术上是可选的。本仓库的惯例是包含该元素。如果您包含
<fullName>
，其值必须与文件名（
.reportType-meta.xml
之前的部分）完全一致——字符、大小写、下划线都必须相同。

错误示例——文件名与

<fullName>

不一致：

文件：
```
account_projects.reportType-meta.xml
```

<fullName>AccountProjects</fullName>

（不匹配：文件使用

account_projects

，fullName使用

AccountProjects

）

正确示例——文件名与

<fullName>

完全一致：

文件：
```
AccountProjects.reportType-meta.xml
```
```
<fullName>AccountProjects</fullName>
```

Rule 2: Join Semantics —

outerJoin

Controls Inclusion

规则2：连接语义——

outerJoin

控制记录包含逻辑

Each

<join>

block has an

<outerJoin>

element that determines which primary records appear in the report:

`<outerJoin>` value	Behavior	Report Builder Label
`false`	Inner join — only primary records that HAVE at least one related record	"Each 'A' record must have at least one related 'B' record"
`true`	Outer join — all primary records, with or without related records	"'A' records may or may not have related 'B' records"

Default when unspecified: Use

true

(outer join) when the user wants to see all primary records regardless of children. Use

false

when the report only makes sense if children exist.

每个

<join>

块都有一个

<outerJoin>

元素，用于确定哪些主对象记录会出现在报表中：

`<outerJoin>` 值	行为	报表构建器标签
`false`	内连接——仅包含至少有一条相关记录的主对象记录	"每个'A'记录必须至少有一条相关的'B'记录"
`true`	外连接——包含所有主对象记录，无论是否有相关记录	"'A'记录可能有也可能没有相关的'B'记录"

未指定时的默认值：当用户希望查看所有主对象记录而不管是否有子记录时，使用

true

（外连接）。当只有存在子记录时报表才有意义时，使用

false

。

Rule 3: Each Object Needs Its Own

<sections>

Block

规则3：每个对象都需要独立的

<sections>

块

Every object in the CRT (primary + each joined object) must have a corresponding

<sections>

block that lists the fields exposed for reporting. Without a section for an object, none of its fields appear in the report builder.

```
<masterLabel>
```
on each section is the section heading in the report builder
```
<columns>
```
entries list the fields — each with a
```
<field>
```
(API name) and
```
<table>
```
(object API name)
For fields reached via lookup, use the relationship path in
```
<field>
```
(e.g.
```
Owner.Name
```
with
```
<table>
```
set to the owning object)

CRT中的每个对象（主对象 + 每个连接对象）都必须有对应的

<sections>

块，列出用于报表的暴露字段。如果某个对象没有对应的节，其所有字段都不会出现在报表构建器中。

每个节的
```
<masterLabel>
```
是报表构建器中的节标题
```
<columns>
```
条目列出字段——每个条目包含
```
<field>
```
（API名称）和
```
<table>
```
（对象API名称）
对于通过查找关系获取的字段，在
```
<field>
```
中使用关系路径（例如
```
Owner.Name
```
，同时
```
<table>
```
设置为所属对象）

Rule 4: Field API Names, Not Labels

规则4：使用字段API名称，而非标签

Use exact API names for fields: standard fields use their defined names (

Name

CreatedDate

OwnerId

), custom fields use

Field__c

. Custom objects must include

__c

Wrong:

```
<field>Account Name</field>
```

Right:

<field>Name</field>

with

<table>Account</table>

使用字段的精确API名称：标准字段使用其定义的名称（

Name

、

CreatedDate

、

OwnerId

），自定义字段使用

Field__c

。自定义对象必须包含

__c

。

错误示例：

```
<field>Account Name</field>
```

正确示例：

<field>Name</field>

搭配

<table>Account</table>

Rule 5: Relationship Path for Joined Objects

规则5：连接对象的关系路径

When adding a

<join>

, the

<relationship>

element must use the child relationship name as defined on the lookup/master-detail field pointing from the child object to the parent. For custom relationships, this typically ends in

__r

Wrong:

```
<relationship>Project</relationship>
```
(for a custom child relationship)

Right:

<relationship>Projects__r</relationship>

(child relationship name)

```
<relationship>Contacts</relationship>
```
(standard, non-custom child relationship)

添加

<join>

时，

<relationship>

元素必须使用子关系名称，即从子对象指向父对象的查找/主明细字段中定义的名称。对于自定义关系，通常以

__r

结尾。

错误示例：

```
<relationship>Project</relationship>
```
（针对自定义子关系）

正确示例：

<relationship>Projects__r</relationship>

（子关系名称）

```
<relationship>Contacts</relationship>
```
（标准非自定义子关系）

Rule 6: Maximum 4 Objects Total in a Join Chain

规则6：连接链中最多包含4个对象

A single CRT can join a maximum of four objects total (the base object + up to 3 additional objects via nested

<join>

blocks).

单个CRT最多可连接4个对象（主对象 + 最多3个通过嵌套

<join>

块添加的额外对象）。

Rule 7: No Inner Join After an Outer Join

规则7：外连接之后不能使用内连接

Once the join chain contains an outer join (

<outerJoin>true</outerJoin>

), every subsequent nested join must also be an outer join. An inner join that follows an outer join earlier in the sequence is not allowed.

Wrong:

xml

<join>
    <outerJoin>true</outerJoin>        <!-- outer join first -->
    <relationship>Contacts</relationship>
    <join>
        <outerJoin>false</outerJoin>   <!-- WRONG: inner join after outer -->
        <relationship>Assets</relationship>
    </join>
</join>

Right:

xml

<join>
    <outerJoin>true</outerJoin>
    <relationship>Contacts</relationship>
    <join>
        <outerJoin>true</outerJoin>    <!-- outer stays outer -->
        <relationship>Assets</relationship>
    </join>
</join>

一旦连接链中包含外连接（

<outerJoin>true</outerJoin>

），后续所有嵌套连接也必须是外连接。不允许在序列中先出现外连接后出现内连接。

错误示例：

xml

<join>
    <outerJoin>true</outerJoin>        <!-- 先使用外连接 -->
    <relationship>Contacts</relationship>
    <join>
        <outerJoin>false</outerJoin>   <!-- 错误：外连接后使用内连接 -->
        <relationship>Assets</relationship>
    </join>
</join>

正确示例：

xml

<join>
    <outerJoin>true</outerJoin>
    <relationship>Contacts</relationship>
    <join>
        <outerJoin>true</outerJoin>    <!-- 外连接保持外连接 -->
        <relationship>Assets</relationship>
    </join>
</join>

Rule 8:

<table>

for Joined Objects Uses Dotted Path

规则8：连接对象的

<table>

使用带点的路径

<sections>

, the

<table>

element identifies which object in the join chain each column belongs to. For the base object, use the object name directly (e.g.

Account

). For joined objects, use the dotted relationship path from the base object.

Object in chain	`<table>` value
Base (Account)	`Account`
First join (Account → Contacts)	`Account.Contacts`
Nested join (Account → Contacts → Assets)	`Account.Contacts.Assets`

在

<sections>

中，

<table>

元素用于标识连接链中每个列所属的对象。对于主对象，直接使用对象名称（例如

Account

）。对于连接对象，使用从主对象出发的带点关系路径。

连接链中的对象	`<table>` 值
主对象（Account）	`Account`
第一层连接（Account → Contacts）	`Account.Contacts`
嵌套连接（Account → Contacts → Assets）	`Account.Contacts.Assets`

Rule 9: Field Paths Can Traverse Lookups

规则9：字段路径可遍历查找关系

<field>

values may reference fields reached via lookup relationships using dot notation — for example

Owner.Email

(owner User's email) or

ReportsTo.CreatedBy.Contact.Owner.MobilePhone

. The

<table>

must still be the object that owns the starting field.

<field>

值可使用点符号引用通过查找关系获取的字段——例如

Owner.Email

（所有者用户的邮箱）或

ReportsTo.CreatedBy.Contact.Owner.MobilePhone

。

<table>

仍需设置为起始字段所属的对象。

Rule 10: Historical Trending Fields Use

_hst

Suffix

规则10：历史趋势字段使用

_hst

后缀

For a field with

trackTrending=true

, the API name in

<field>

and

<table>

uses the

_hst

suffix:

xml

<columns>
    <checkedByDefault>false</checkedByDefault>
    <field>Field2__c_hst</field>
    <table>CustomTrendedObject__c.CustomTrendedObject__c_hst</table>
</columns>

对于

trackTrending=true

的字段，

<field>

和

<table>

中的API名称需使用

_hst

后缀：

xml

<columns>
    <checkedByDefault>false</checkedByDefault>
    <field>Field2__c_hst</field>
    <table>CustomTrendedObject__c.CustomTrendedObject__c_hst</table>
</columns>

Rule 11: Primary Object Cannot Be Changed After Deployment

规则11：部署后主对象无法修改

Once deployed, the

<baseObject>

of a CRT is locked. To change the primary object, create a new CRT and retire the old one.

CRT部署后，

<baseObject>

将被锁定。如需修改主对象，需创建新的CRT并停用旧的CRT。

Rule 12:

autogenerated

Is Reserved for Historical Trending

规则12：

autogenerated

为历史趋势专用

The

<autogenerated>

element (API 29.0+) marks CRTs that Salesforce created automatically when historical trending was enabled on an object. Do not set this manually on hand-authored CRTs.

<autogenerated>

元素（API 29.0+）用于标记当对象启用历史趋势时Salesforce自动创建的CRT。请勿在手动编写的CRT中手动设置该元素。

Generation Workflow

生成流程

Step 1: Gather Requirements

步骤1：收集需求

Primary object API name (e.g.
```
Account
```
,
```
Project__c
```
)
Related objects and the relationship between each (which has the lookup/master-detail to which)
For each relationship: inner join (children required) or outer join (children optional)?
Which fields to expose per object — aim for task-relevant, not the full field list
Audience and category — where should this appear in the report builder picker?
Whether this ships as
```
deployed=true
```
now or stays
```
deployed=false
```
during iteration

主对象API名称（例如
```
Account
```
、
```
Project__c
```
）
相关对象及其相互关系（哪个对象拥有指向哪个对象的查找/主明细字段）
每个关系的类型：内连接（需要子记录）还是外连接（子记录可选）？
每个对象需要暴露哪些字段——目标是与任务相关的字段，而非完整字段列表
受众和类别——该CRT应出现在报表构建器选择器的哪个位置？
当前是否设置为
```
deployed=true
```
供用户使用，还是设置为
```
deployed=false
```
进行迭代

Step 2: Examine Existing Examples

步骤2：查看现有示例

Look in the project for in-project CRT patterns
If existing report types have been retrieved from an org, compare against those structures

在项目中查找内部CRT模式
如果已从组织中获取现有报表类型，对比其结构

Step 3: Write the Specification

步骤3：编写规范

Document before authoring:

```
fullName
```
and
```
label
```
```
baseObject
```
Category and
```
deployed
```
state
Join chain: for each related object — relationship name, outer vs inner join
Section layout: one section per object, ordered list of fields
Acceptance criteria: which records should appear when the report runs, which fields are available in the builder

在编写元数据前先记录：

```
fullName
```
和
```
label
```
```
baseObject
```
类别和
```
deployed
```
状态
连接链：每个相关对象的关系名称、外连接/内连接类型
节布局：每个对象对应一个节，字段有序列表
验收标准：报表运行时应显示哪些记录，构建器中可用哪些字段

Step 4: Author the Metadata File

步骤4：编写元数据文件

Start from the closest example in

examples/

and adapt it to the user's scenario:

Primary object only (no joins) →

examples/AccountsWithIndustry.reportType-meta.xml

Outer join (primary records included even without children) →
```
examples/AccountsWithProjects.reportType-meta.xml
```

Nested inner join (every level requires children) →

examples/AccountProjectsWithTasks.reportType-meta.xml

Name the file

<DeveloperName>.reportType-meta.xml

从

examples/

中最接近的示例开始，根据用户场景进行调整：

仅主对象（无连接）→

examples/AccountsWithIndustry.reportType-meta.xml

外连接（即使无子记录也包含主对象记录）→
```
examples/AccountsWithProjects.reportType-meta.xml
```

嵌套内连接（每一层都需要子记录）→

examples/AccountProjectsWithTasks.reportType-meta.xml

将文件命名为

<DeveloperName>.reportType-meta.xml

。

Step 5: Validate

步骤5：验证

Well-formed XML with correct namespace (

xmlns="http://soap.sforce.com/2006/04/metadata"

)

File name (without
```
.reportType-meta.xml
```
) matches
```
<fullName>
```
when
```
<fullName>
```
is included
```
<baseObject>
```
is a valid API name and the object is deployed
Every
```
<relationship>
```
uses the correct child relationship name (
```
__r
```
suffix for custom)
Each object referenced in
```
<sections>
```
is part of the CRT (primary or joined)
All
```
<field>
```
references exist on the parent
```
<table>
```
and use API names (not labels)
```
<category>
```
is a valid Salesforce category value
```
<deployed>
```
is
```
true
```
if users need to access the CRT immediately

XML格式正确，命名空间正确（

xmlns="http://soap.sforce.com/2006/04/metadata"

）

当包含
```
<fullName>
```
时，文件名（不含
```
.reportType-meta.xml
```
）与
```
<fullName>
```
匹配
```
<baseObject>
```
是有效的API名称且该对象已部署
每个
```
<relationship>
```
使用正确的子关系名称（自定义关系以
```
__r
```
结尾）
```
<sections>
```
中引用的每个对象都属于CRT（主对象或连接对象）
所有
```
<field>
```
引用都存在于父
```
<table>
```
中，且使用API名称（而非标签）
```
<category>
```
是有效的Salesforce类别值
如果用户需要立即访问CRT，
```
<deployed>
```
设置为
```
true
```

Reference File Index

参考文件索引

File	When to read
`examples/AccountsWithIndustry.reportType-meta.xml`	Step 2 / Step 4 — primary-object-only template
`examples/AccountsWithProjects.reportType-meta.xml`	Step 2 / Step 4 — outer-join template (primary included even without children)
`examples/AccountProjectsWithTasks.reportType-meta.xml`	Step 2 / Step 4 — nested inner-join template (every level requires children)
`references/category-values.md`	Step 3 — to choose a valid `<category>` value from the `ReportTypeCategory` enum
`references/errors-and-troubleshooting.md`	When fields don't appear in the report builder or join requirements conflict

文件	阅读场景
`examples/AccountsWithIndustry.reportType-meta.xml`	步骤2 / 步骤4 —— 仅主对象模板
`examples/AccountsWithProjects.reportType-meta.xml`	步骤2 / 步骤4 —— 外连接模板（即使无子记录也包含主对象）
`examples/AccountProjectsWithTasks.reportType-meta.xml`	步骤2 / 步骤4 —— 嵌套内连接模板（每一层都需要子记录）
`references/category-values.md`	步骤3 —— 从 `ReportTypeCategory` 枚举中选择有效的 `<category>` 值
`references/errors-and-troubleshooting.md`	当字段未出现在报表构建器中或连接要求冲突时

Verification Checklist

验证清单

Universal Checks

通用检查

File extension is
```
.reportType-meta.xml
```
File basename satisfies the developer-name rules (begins with a letter, only letters/numbers/underscores, no spaces, no trailing underscore, no consecutive underscores)
If
```
<fullName>
```
is included, it matches the file basename exactly (same characters, casing, and underscores)
```
<label>
```
is human-readable and under 40 characters
```
<description>
```
explains the business purpose
```
<baseObject>
```
uses a valid API name and that object is deployed
```
<category>
```
is a valid
```
ReportTypeCategory
```
enum value
```
<deployed>
```
is set appropriately (
```
true
```
for user access,
```
false
```
for in-progress iteration)
```
<autogenerated>
```
is NOT set manually (reserved for historical-trending CRTs)

文件扩展名为
```
.reportType-meta.xml
```
文件基名符合开发者名称规则（以字母开头，仅包含字母/数字/下划线，无空格，无末尾下划线，无连续下划线）
如果包含
```
<fullName>
```
，其值与文件基名完全一致（字符、大小写、下划线均相同）
```
<label>
```
易于理解且长度不超过40个字符
```
<description>
```
说明了业务用途
```
<baseObject>
```
使用有效的API名称且该对象已部署
```
<category>
```
是有效的
```
ReportTypeCategory
```
枚举值
```
<deployed>
```
设置合理（
```
true
```
供用户访问，
```
false
```
用于迭代中）
未手动设置
```
<autogenerated>
```
（为历史趋势CRT专用）

Join Checks

连接检查

Each
```
<join>
```
uses the correct child relationship name (not the lookup field API name)
Custom relationships use
```
__r
```
suffix
```
<outerJoin>
```
is set intentionally:
```
true
```
= optional children,
```
false
```
= required children
No inner join (
```
<outerJoin>false</outerJoin>
```
) appears after an outer join earlier in the sequence
Total object count (base + joins, including nested) is 4 or fewer

每个
```
<join>
```
使用正确的子关系名称（而非查找字段API名称）
自定义关系使用
```
__r
```
后缀
```
<outerJoin>
```
设置符合预期：
```
true
```
= 子记录可选，
```
false
```
= 子记录必填
序列中先出现外连接后，未出现内连接（
```
<outerJoin>false</outerJoin>
```
）
对象总数（主对象 + 连接对象，包括嵌套）不超过4个

Section Checks

节检查

Every object in the CRT has a corresponding
```
<sections>
```
block
```
<masterLabel>
```
on each section is descriptive
Every
```
<columns>
```
has both
```
<field>
```
(API name) and
```
<table>
```
(object API name or dotted path)
```
<checkedByDefault>
```
is set for each column
```
<table>
```
for base object is the object API name (e.g.
```
Account
```
)
```
<table>
```
for joined objects uses the dotted relationship path (e.g.
```
Account.Projects__r
```
,
```
Account.Projects__r.Tasks__r
```
)
Field references use API names (not labels); custom fields use
```
__c
```
Lookup traversal fields use dot notation (e.g.
```
Owner.Email
```
) with
```
<table>
```
set to the object owning the starting field
Historical trending fields use
```
_hst
```
suffix in both
```
<field>
```
and
```
<table>
```
when applicable
No duplicate fields within a section

CRT中的每个对象都有对应的
```
<sections>
```
块
每个节的
```
<masterLabel>
```
描述清晰
每个
```
<columns>
```
都包含
```
<field>
```
（API名称）和
```
<table>
```
（对象API名称或带点路径）
每个列都设置了
```
<checkedByDefault>
```
主对象的
```
<table>
```
为对象API名称（例如
```
Account
```
）
连接对象的
```
<table>
```
使用带点的关系路径（例如
```
Account.Projects__r
```
、
```
Account.Projects__r.Tasks__r
```
）
字段引用使用API名称（而非标签）；自定义字段使用
```
__c
```
查找遍历字段使用点符号（例如
```
Owner.Email
```
），且
```
<table>
```
设置为起始字段所属的对象
适用时，历史趋势字段在
```
<field>
```
和
```
<table>
```
中均使用
```
_hst
```
后缀
节内无重复字段

platform-custom-report-type-generate

Original

Translation

Specification

规范

Salesforce Custom Report Type Metadata Knowledge

Salesforce Custom Report Type元数据知识

Overview

概述

Purpose

用途

Configuration

配置

Key Elements

关键元素

Critical Rules (Read First)

重要规则（请先阅读）

Rule 1: If <fullName> Is Present, It Must Match the File Name

规则1：如果包含<fullName>，必须与文件名匹配

Rule 2: Join Semantics — outerJoin Controls Inclusion

规则2：连接语义——outerJoin控制记录包含逻辑

Rule 3: Each Object Needs Its Own <sections> Block

规则3：每个对象都需要独立的<sections>块

Rule 4: Field API Names, Not Labels

规则4：使用字段API名称，而非标签

Rule 5: Relationship Path for Joined Objects

规则5：连接对象的关系路径

Rule 6: Maximum 4 Objects Total in a Join Chain

规则6：连接链中最多包含4个对象

Rule 7: No Inner Join After an Outer Join

规则7：外连接之后不能使用内连接

Rule 8: <table> for Joined Objects Uses Dotted Path

规则8：连接对象的<table>使用带点的路径

Rule 9: Field Paths Can Traverse Lookups

规则9：字段路径可遍历查找关系

Rule 10: Historical Trending Fields Use _hst Suffix

规则10：历史趋势字段使用_hst后缀

Rule 11: Primary Object Cannot Be Changed After Deployment

规则11：部署后主对象无法修改

Rule 12: autogenerated Is Reserved for Historical Trending

规则12：autogenerated为历史趋势专用

Generation Workflow

生成流程

Step 1: Gather Requirements

步骤1：收集需求

Step 2: Examine Existing Examples

步骤2：查看现有示例

Step 3: Write the Specification

步骤3：编写规范

Step 4: Author the Metadata File

步骤4：编写元数据文件

Step 5: Validate

步骤5：验证

Reference File Index

参考文件索引

Verification Checklist

验证清单

Universal Checks

通用检查

Join Checks

连接检查

Section Checks

节检查

Rule 1: If
`<fullName>`
Is Present, It Must Match the File Name

规则1：如果包含
`<fullName>`
，必须与文件名匹配

Rule 2: Join Semantics —
`outerJoin`
Controls Inclusion

规则2：连接语义——
`outerJoin`
控制记录包含逻辑

Rule 3: Each Object Needs Its Own
`<sections>`
Block

规则3：每个对象都需要独立的
`<sections>`
块

Rule 8:
`<table>`
for Joined Objects Uses Dotted Path

规则8：连接对象的
`<table>`
使用带点的路径

Rule 10: Historical Trending Fields Use
`_hst`
Suffix

规则10：历史趋势字段使用
`_hst`
后缀

Rule 12:
`autogenerated`
Is Reserved for Historical Trending

规则12：
`autogenerated`
为历史趋势专用