platform-data-and-tooling-api-context-get

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Salesforce Data + Tooling API Skill

Salesforce 数据与 Tooling API 技能

This skill provides field-level reference for 2130 standard Salesforce objects across two runtime API surfaces: the Enterprise/Data API (standard sObjects you query with SOQL and modify with DML) and the Tooling API (developer/metadata-adjacent records like

ApexClass

ApexCodeCoverage

TraceFlag

, and

EntityDefinition

Use it to look up authoritative field names, types, and properties before writing SOQL/SOSL, building DML, or reading records at runtime — so queries and writes don't fail with

INVALID_FIELD

/ "No such column" errors.

Standard objects only. These assets cover standard sObjects and Tooling records. Custom
__c
objects, and custom
__c
fields on standard objects, are not in this corpus — they don't exist as static docs pages. For those, describe the live org instead (
sf sobject describe --sobject <Name>
).

本技能为2130个标准Salesforce对象提供字段级参考，覆盖两个运行时API层面：企业/数据API（可通过SOQL查询、DML修改的标准sObject）和Tooling API（与开发者/元数据相关的记录，如

ApexClass

、

ApexCodeCoverage

、

TraceFlag

和

EntityDefinition

）。

使用它在编写SOQL/SOSL、构建DML或运行时读取记录之前，查询权威的字段名称、类型和属性——避免查询和写入操作因

INVALID_FIELD

/ "无此列"错误而失败。

仅适用于标准对象。本资源覆盖标准sObject和Tooling记录。自定义
__c
对象以及标准对象上的自定义
__c
字段不在此语料库中——它们不存在于静态文档页面中。如需查询这些内容，请描述实际组织（使用
sf sobject describe --sobject <名称>
命令）。

Overview

概述

Each object is documented as a JSON file with:

Field definitions: name, type, and properties (Createable, Filterable, Groupable, Nillable, Sortable, Updateable)
Relationship metadata (relationship name, referenced object, relationship type) for enterprise sObjects
Supported SOAP calls and REST HTTP methods for Tooling records
WSDL schema segment
Usage notes and associated objects (enterprise sObjects)

This skill is for runtime data, not deployment. For authoring
*-meta.xml
source files (CustomObject, Flow, Profile, ...) use the Metadata API skill (
platform-metadata-api-context-get
). The two are companions, not substitutes.

每个对象都以JSON文件形式记录，包含：

字段定义：名称、类型和属性（可创建、可筛选、可分组、可为空、可排序、可更新）
关系元数据（关系名称、引用对象、关系类型）（针对企业级sObject）
Tooling记录支持的SOAP调用和REST HTTP方法
WSDL架构片段
使用说明和关联对象（针对企业级sObject）

本技能适用于运行时数据，而非部署场景。如需编写
*-meta.xml
源文件（CustomObject、Flow、Profile等），请使用Metadata API技能（
platform-metadata-api-context-get
）。两者互为补充，而非替代关系。

How to Use This Skill

如何使用本技能

CRITICAL: Field-Existence Gate (do this BEFORE answering)

关键：字段存在性检查（回答前必须执行）

NEVER answer a field question — "does field X exist?", "is X filterable/sortable/groupable?", "what's X's API name/type?" — from memory or training data. This includes obvious system fields like
Id
,
Name
,
CreatedDate
,
LastModifiedDate
,
OwnerId
,
IsDeleted
. ALWAYS run the lookup first. You know these fields from training, but this skill exists precisely because your recollection of their properties (Filter/Sort/Group) and of which catalog documents them is unreliable. Confidence is not verification.

Run ONE atomic command that checks BOTH catalogs at once (a field can live in

fields

, in

field_reference

, or neither — see the dual-catalog note below):

bash

jq '{fields: .fields["<FieldName>"], field_reference: .field_reference["<FieldName>"]}' assets/enterprise_api/<Object>.json

**绝不要仅凭记忆或训练数据回答字段相关问题——比如“字段X是否存在？”、“X是否可筛选/可排序/可分组？”、“X的API名称/类型是什么？”——包括Id、Name、CreatedDate、LastModifiedDate、OwnerId、IsDeleted等明显的系统字段。务必先执行查询操作。**你可能通过训练知道这些字段，但本技能的存在正是因为你对它们的属性（筛选/排序/分组）以及对应的文档目录的记忆不可靠。自信不等于验证。

运行一个原子命令同时检查两个目录（字段可能存在于

fields

、

field_reference

中，或两者都不存在——请参阅下文的双目录说明）：

bash

jq '{fields: .fields["<FieldName>"], field_reference: .field_reference["<FieldName>"]}' assets/enterprise_api/<Object>.json

e.g. checking CreatedDate on Account:

示例：检查Account对象的CreatedDate字段：

jq '{fields: .fields["CreatedDate"], field_reference: .field_reference["CreatedDate"]}' assets/enterprise_api/Account.json


Interpret the result: found in `fields` → use its `properties` for capability answers. Found only in `field_reference` → it exists, but Filter/Sort/Group **cannot** be determined from this skill (that catalog carries no property flags). `null` in both → not in this corpus (may still be a real live-org/custom field — describe the org).

**MANDATORY VERIFICATION GATE.** Before you state any field fact, you MUST first print this line verbatim in your reply to the user (like the metadata skill's status line):

```text
field_lookup: object=<Object> field=<FieldName> checked_fields=<yes|no> checked_field_reference=<yes|no> result=<in_fields|in_field_reference|not_found>

If you cannot print this line truthfully with both checks =

yes

, you have not done the lookup — stop and run the jq command. Do not fabricate a citation like "based on the skill's data" without having run it.

This gate line is a self-verification marker for your conversational response only — do NOT write it into files you generate for the user (

.soql

.md

.json

, query comment headers, etc.). Deliverables should contain just the answer/query the user asked for; keep the

field_lookup:

line out of them.

jq '{fields: .fields["CreatedDate"], field_reference: .field_reference["CreatedDate"]}' assets/enterprise_api/Account.json


解读结果：在`fields`中找到→使用其`properties`回答能力相关问题。仅在`field_reference`中找到→字段存在，但无法通过本技能确定其筛选/排序/分组能力（该目录不包含属性标记）。两者均为`null`→不在此语料库中（可能仍是实际组织中的真实字段/自定义字段——请描述组织）。

**强制验证检查**。在向用户陈述任何字段相关事实之前，必须在回复中逐字打印以下内容（类似元数据技能的状态行）：

```text
field_lookup: object=<Object> field=<FieldName> checked_fields=<yes|no> checked_field_reference=<yes|no> result=<in_fields|in_field_reference|not_found>

如果无法如实打印此行且两个检查项均为

yes

，则说明你未执行查询——请停止操作并运行上述jq命令。不要在未执行查询的情况下编造诸如“基于技能数据”的引用。

此检查行仅用于对话回复中的自我验证标记——请勿将其写入为用户生成的文件（

.soql

、

.md

、

.json

、查询注释头等）。交付内容应仅包含用户所需的答案/查询；请勿将

field_lookup:

行包含在内。

CRITICAL: Section-Specific Consumption

关键：特定章节读取

ALWAYS consume only the specific sections you need from JSON files, NOT entire files.

For
assets/enterprise_api/*.json
and
assets/tooling_api/*.json
files, always use
jq
or programmatic JSON parsing to extract only the sections you need. Do not load these files whole via

Read

cat

, or

read_file

— they contain verbose

wsdl_segment

and

field_reference

sections that waste 60-80% of tokens on large sObjects like Account.

Each JSON file contains multiple sections. Most use cases only need 1-2:

For query/DML field lists: load only the
```
fields
```
section
For relationship traversal: load
```
fields
```
(the
```
relationship_name
```
/
```
refers_to
```
columns are inline)

For Tooling call support: load

supported_soap_calls

supported_rest_api_http_methods

For "can this user query it?" / permission questions: load
```
special_access_rules
```
(present on both surfaces when the object documents access gates)
For query ceilings / unsupported clauses (record caps, no
```
ORDER BY
```
/
```
queryMore()
```
/
```
OFFSET
```
): load
```
limitations
```
— present only on objects that impose them
Skip by default:
```
wsdl_segment
```
,
```
ispersonaccount_fields
```

Dual-catalog rule (imperative — this is the one people get wrong):

A field can be in
```
fields
```
, in
```
field_reference
```
, in both, or in neither. These are two DIFFERENT catalogs, not a superset relationship.
A miss in
fields
is NOT a "field doesn't exist" answer. Check
```
field_reference
```
too before concluding anything — the atomic jq command above does both in one shot.
Filter/Sort/Group/Create/Update/Nillable properties come only from
```
fields
```
. A field found only in
```
field_reference
```
has NO retrievable capability flags here — say so; don't guess.

<details> <summary><b>Why the two catalogs differ (reference — optional reading)</b></summary>

fields

comes from Salesforce's SOAP "Fields" table (query/DML properties: Create/Filter/Sort/Group/Update/Nillable).

field_reference

comes from a different UI-facing "Field List" table (label/length/precision/scale) that some objects document separately from the SOAP table — and it can include many fields

fields

never lists at all (e.g. objects with very large boolean-flag catalogs, or assorted admin-facing fields the SOAP table omits). Across the corpus, thousands of fields exist ONLY in

field_reference

, and a smaller number exist only in

fields

. This is why a field-existence answer requires checking both, and why capability questions can only be answered from

fields

</details>

始终仅从JSON文件中读取所需的特定章节，而非整个文件。

对于
assets/enterprise_api/*.json
和
assets/tooling_api/*.json
文件，请始终使用
jq
或程序化JSON解析提取所需的章节。不要通过

Read

、

cat

或

read_file

加载整个文件——这些文件包含冗长的

wsdl_segment

和

field_reference

章节，对于Account等大型sObject，会浪费60-80%的令牌。

每个JSON文件包含多个章节。大多数使用场景仅需1-2个章节：

查询/DML字段列表：仅加载
```
fields
```
章节
关系遍历：加载
```
fields
```
章节（
```
relationship_name
```
/
```
refers_to
```
列内嵌其中）

Tooling调用支持：加载

supported_soap_calls

supported_rest_api_http_methods

章节

“用户能否查询该对象？”/权限问题：加载
```
special_access_rules
```
章节（当对象记录了访问限制时，两个API层面都会包含此章节）
查询限制/不支持的子句（记录上限、不支持
```
ORDER BY
```
/
```
queryMore()
```
/
```
OFFSET
```
）：加载
```
limitations
```
章节——仅在对象存在此类限制时包含
默认跳过：
```
wsdl_segment
```
、
```
ispersonaccount_fields
```

双目录规则（强制要求——这是容易出错的点）：

字段可能存在于
```
fields
```
、
```
field_reference
```
、两者都存在，或两者都不存在。这是两个不同的目录，而非超集关系。
fields
中未找到并不代表“字段不存在”。在得出结论之前，务必同时检查
```
field_reference
```
——上述原子jq命令可一次性完成两项检查。
筛选/排序/分组/创建/更新/可为空属性仅来自
```
fields
```
章节。仅在
```
field_reference
```
中找到的字段无法获取可检索的能力标记——请如实说明，不要猜测。

<details> <summary><b>两个目录存在差异的原因（参考——可选阅读）</b></summary>

fields

来自Salesforce的SOAP“字段”表（查询/DML属性：创建/筛选/排序/分组/更新/可为空）。

field_reference

来自另一个面向UI的“字段列表”表（标签/长度/精度/比例），某些对象会单独记录此表，而非SOAP表——并且它可能包含许多

fields

从未列出的字段（例如具有大量布尔标记目录的对象，或SOAP表省略的各种面向管理员的字段）。在整个语料库中，数千个字段仅存在于

field_reference

中，还有少量字段仅存在于

fields

中。这就是为什么字段存在性检查需要同时查看两个目录，而能力相关问题只能通过

fields

回答。

</details>

Which folder?

选择哪个文件夹？

Standard sObjects you query and modify at runtime (Account, Contact, Opportunity, Lead, Case, ...) →
```
assets/enterprise_api/
```
Developer / diagnostics records (ApexClass, ApexCodeCoverageAggregate, TraceFlag, EntityDefinition, MetadataComponentDependency, SymbolTable) →
```
assets/tooling_api/
```
Custom
__c
objects and custom
__c
fields → NOT in these assets. Describe the live org:
```
sf sobject describe --sobject <Name> --target-org <alias>
```
. (A custom field like
```
Region__c
```
on standard Account won't be in
```
assets/enterprise_api/Account.json
```
either.)

运行时可查询和修改的标准sObject（Account、Contact、Opportunity、Lead、Case等）→
```
assets/enterprise_api/
```
开发者/诊断记录（ApexClass、ApexCodeCoverageAggregate、TraceFlag、EntityDefinition、MetadataComponentDependency、SymbolTable）→
```
assets/tooling_api/
```
自定义
__c
对象和自定义
__c
字段→ 不在此资源范围内。请描述实际组织：
```
sf sobject describe --sobject <名称> --target-org <别名>
```
。（标准Account对象上的自定义字段如
```
Region__c
```
也不会出现在
```
assets/enterprise_api/Account.json
```
中。）

Example Queries (Section-Specific)

示例查询（特定章节）

Do:

"Show me only the 'fields' section from assets/enterprise_api/Account.json"
"What are the filterable fields on Opportunity?"
"Which fields on Contact are relationships, and what do they refer to?"
"What SOAP calls does ApexClass support in the Tooling API?"
"Field X isn't in
```
fields
```
— check
```
field_reference
```
before saying it doesn't exist"

Don't:

"Load Account.json" (pulls the huge
```
wsdl_segment
```
; load
```
fields
```
and
```
field_reference
```
separately instead of the whole file)

推荐做法：

“仅显示assets/enterprise_api/Account.json中的'fields'章节”
“Opportunity对象上哪些字段可筛选？”
“Contact对象上哪些字段是关系字段，它们引用了哪些对象？”
“Tooling API中ApexClass支持哪些SOAP调用？”
“字段X不在
```
fields
```
中——在说它不存在之前，请检查
```
field_reference
```
”

不推荐做法：

“加载Account.json”（会加载庞大的
```
wsdl_segment
```
；请分别加载
```
fields
```
和
```
field_reference
```
章节，而非整个文件）

JSON File Structure

JSON文件结构

Enterprise (data) sObjects live in

assets/enterprise_api/

; Tooling records live in

assets/tooling_api/

. Both share a common core, with a few surface-specific sections.

json

{
  "sections": ["title", "description", "fields", "wsdl_segment", ...],
  "title": "Account | Enterprise API",
  "description": "Plain-text description of the object.",
  "fields_columns": ["type", "properties", "description", "relationship_name", "refers_to", "relationship_type"],
  "fields": {
    "fieldName": {
      "type": "string | reference | picklist | ...",
      "properties": "Create, Filter, Group, Nillable, Sort, Update",
      "description": "Field description",
      "relationship_name": "(reference fields only)",
      "refers_to": "(reference fields only) e.g. Account"
    }
  },
  "wsdl_segment": "<xsd:complexType>...</xsd:complexType>"
}

fields

is a dict keyed by field API name (e.g.

fields["AnnualRevenue"]

), not a list — iterate with

.items()

.keys()

, don't index it positionally.

企业级（数据）sObject位于

assets/enterprise_api/

；Tooling记录位于

assets/tooling_api/

。两者共享核心结构，仅部分章节因API层面而异。

json

{
  "sections": ["title", "description", "fields", "wsdl_segment", ...],
  "title": "Account | Enterprise API",
  "description": "对象的纯文本描述。",
  "fields_columns": ["type", "properties", "description", "relationship_name", "refers_to", "relationship_type"],
  "fields": {
    "fieldName": {
      "type": "string | reference | picklist | ...",
      "properties": "Create, Filter, Group, Nillable, Sort, Update",
      "description": "字段描述",
      "relationship_name": "(仅参考字段)",
      "refers_to": "(仅参考字段) 例如：Account"
    }
  },
  "wsdl_segment": "<xsd:complexType>...</xsd:complexType>"
}

fields

是一个以字段API名称为键的字典（例如

fields["AnnualRevenue"]

），而非列表——请使用

.items()

.keys()

遍历，不要按位置索引。

How sections are derived (read this before assuming a section list)

章节的派生方式（在假设章节列表之前阅读此内容）

Each JSON file is generated from whatever
## Heading
sections actually appear on that object's Salesforce docs page — the JSON schema is not a fixed, uniform template applied identically to every object. Two consequences follow directly from that:

No section is guaranteed present on every object,
fields
included. A section exists in a file only if the source docs page had a matching heading. Some Tooling docs pages have no fields table at all (thin/beta pages), so
```
fields
```
can be missing; a small number of SOAP-header-style pages label their field table singular (
```
field
```
) instead of plural. Always check the file's own
sections
array (or
"fields" in sections
) before assuming a section exists — don't hard code an expectation from having looked at one or two example objects.
A page can carry extra sections beyond the common ones, one per additional
```
##
```
heading Salesforce's docs used on that specific page (e.g. a nested complex type referenced by a field, like a picklist's value-metadata description, or a record-type-info block). These are normalized into
```
snake_case
```
keys and stored either as their own top-level section, or — when the converter recognizes the heading as a distinct sub-type rather than a plain content section — nested under a
```
sub_types
```
dict keyed by the sub-type's name. Treat the "Available Sections" list below as the common/frequent case, not an exhaustive enum — the authoritative list for any one object is that object's own
```
sections
```
array.

每个JSON文件都是从该对象的Salesforce文档页面上实际存在的
## 标题
章节生成的——JSON架构并非固定统一的模板，不会完全相同地应用于每个对象。由此直接产生两个结果：

没有任何章节保证存在于所有对象中，包括
fields
。仅当源文档页面有匹配的标题时，章节才会存在于文件中。某些Tooling文档页面根本没有字段表（内容较少的测试版页面），因此
```
fields
```
可能缺失；少数SOAP头样式页面将其字段表标记为单数形式（
```
field
```
）而非复数形式。请始终检查文件自身的
sections
数组（或
"fields" in sections
），不要假设章节存在——不要因为查看了一两个示例对象就硬编码预期。
页面可能包含超出常见章节的额外章节，每个额外的
```
##
```
标题都会成为一个章节（例如字段引用的嵌套复杂类型，如选择列表的值元数据描述，或记录类型信息块）。这些章节会被规范化为
```
snake_case
```
键，要么作为顶级章节存储，要么当转换器识别到标题为不同的子类型而非普通内容章节时，嵌套在
```
sub_types
```
字典下（按键为子类型名称）。请将下方的“可用章节”列表视为常见/频繁情况，而非详尽枚举——任何单个对象的权威章节列表是该对象自身的
```
sections
```
数组。

Available Sections (common case — not exhaustive; see above)

可用章节（常见情况——非详尽；请参阅上文）

```
title
```
,
```
description
```
,
```
fields_columns
```
: present on essentially all objects
```
fields
```
: present on the large majority of objects, but see point 1 above — verify via
```
sections
```
rather than assuming

Enterprise-only:

usage

associated_objects

ispersonaccount_fields

field_reference

field_reference_columns

Tooling-only:

supported_soap_calls

supported_rest_api_http_methods

```
special_access_rules
```
: who can query/access the object and any permission or license gate (e.g. "Customer Portal users can't access this object", "requires Omnistudio licenses"). Present on both surfaces. Read this before concluding a query will run for a given user — it's a query-eligibility fact no field flag captures.
```
limitations
```
: query ceilings and unsupported SOQL clauses the object imposes (e.g. MetadataComponentDependency: max 2000 records via Tooling API / 100,000 via Bulk API 2.0;
```
ORDER BY
```
,
```
OFFSET
```
,
```
queryMore()
```
, and
```
*Name
```
-field filters are not supported). Read this before writing a query against an object that has it — these constraints are not derivable from the
```
fields
```
properties.
```
wsdl_segment
```
: schema definition (verbose — skip unless you need the raw type)
```
sub_types
```
and any other
```
snake_case
```
-named section not listed above: object-specific nested schema description, present only when that object's docs page had a matching heading — inspect the file's
```
sections
```
array to discover them per-object

The

fields_columns

array tells you which columns each object's

fields

entries carry — check it per-object rather than assuming a fixed shape. Enterprise sObjects typically add

relationship_name

refers_to

, and

relationship_type

; Tooling records typically carry only

type

properties

description

— but a meaningful minority of Tooling objects also carry

relationship_type

, so don't treat it as enterprise-exclusive.

relationship_type

values also have spelling variants in the source data (e.g.

"Lookup"

vs.

"Look up"

) — compare loosely (e.g.

.replace(" ", "").lower()

) rather than exact string equality.

Type strings are case-inconsistent across objects — do not assume a single casing. The same concept appears under multiple castings depending on the source doc page:

string

String

boolean

Boolean

dateTime

DateTime

datetime

. Compare

type

values case-insensitively (e.g.

.lower()

) rather than with

==

against one casing. Beyond the common

string | reference | picklist

types, real data also includes

int

boolean

double

currency

date

dateTime

textarea

address

url

phone

email

time

anyType

base64

, and others — treat the type list as open-ended.

A field can lack structured
type
/
properties
even when the object otherwise has them — check
description
as a fallback before concluding the data is missing. Because each object's JSON is generated from that object's own docs page, a page that presents a field's type/properties as prose (

"Type: ... Properties: ... Description: ..."

) inside a single description paragraph — rather than as separate table columns — produces a

fields

entry with

type

properties

empty and that prose stuffed into

description

. This shows up for a range of reasons (generic template pages reused across many standard objects, e.g. history/share/feed-tracking companion objects) and can affect anywhere from one field to every field on an object — in the worst case

fields_columns

itself may say only

["description"]

. If
type
/
properties
is empty or
fields_columns
looks suspiciously thin, check whether
description
starts with
"Type: "
and parse it as a fallback before concluding the field/object has no type information.

Picklist allowed values sometimes appear in
description
prose — check before assuming they're absent. No

fields

entry has a structured

picklistValues

list. Whether a picklist's allowed values are enumerated in

description

(as

"Possible values are: ..."

followed by the values) depends entirely on whether the source docs page enumerated them for that specific field — many do, many don't (e.g. org-configurable picklists backed by a separate value-set object typically only give illustrative examples like "such as New, Closed, or Escalated" instead of a full list). When present, the format itself is inconsistent — sometimes bare space/comma-separated tokens, sometimes

Value—explanation

em-dash pairs per line — so there's no single reliable regex; extract the substring after

"Possible values are:"

and parse case-by-case, and don't assume every picklist has a discoverable value set here.

A field's
description
may reference a relationship (e.g. "this is a dependent picklist", "this field controls X") without naming or resolving the other side of that relationship — the enterprise sObject's own
fields
section is not always where that answer lives. The Tooling API side of this dataset documents Salesforce's field-metadata objects (schema-about-schema, e.g. an object exposing per-field describe-style attributes) which can carry structured attributes — like a controlling field's identity for a dependent picklist — that the enterprise sObject's docs page never named explicitly. If an enterprise field's description points at a relationship it doesn't resolve, check whether a Tooling-side field-metadata object answers it before concluding the data doesn't exist anywhere in this skill.

A given object's JSON can carry sections beyond the common list above — inspect that object's own
sections
array rather than assuming a closed set. Any additional

##

heading on the source docs page becomes its own

snake_case

-named section (or, when the converter recognizes it as a distinct nested type, a

sub_types

entry). These appear only on the specific objects whose docs happened to include that heading — a per-object schema-description payload, not junk to ignore. There's no fixed enumeration of every possible extra section name; discover them per-object via

sections

See the Index Table for the full object listing and per-object extra sections — it's ~125 KB, so

grep -i "<ObjectName>"

it for a single lookup rather than reading the whole file.

More detail: worked query/DML examples, relationship-traversal patterns, and a full section glossary live in
references/usage_guide.md
. Load it with the
Read
tool only when needed.

```
title
```
、
```
description
```
、
```
fields_columns
```
：几乎所有对象都包含
```
fields
```
：大多数对象包含，但请参阅上文第1点——通过
```
sections
```
验证，不要假设存在

仅企业级API：

usage

、

associated_objects

、

ispersonaccount_fields

、

field_reference

、

field_reference_columns

仅Tooling API：

supported_soap_calls

、

supported_rest_api_http_methods

```
special_access_rules
```
：谁可以查询/访问该对象，以及任何权限或许可证限制（例如“客户门户用户无法访问此对象”、“需要Omnistudio许可证”）。两个API层面都包含此章节。在得出查询对特定用户可行的结论之前，请阅读此章节——这是字段标记无法捕获的查询资格事实。
```
limitations
```
：对象施加的查询限制和不支持的SOQL子句（例如MetadataComponentDependency：通过Tooling API最多返回2000条记录/通过Bulk API 2.0最多返回100,000条记录；不支持
```
ORDER BY
```
、
```
OFFSET
```
、
```
queryMore()
```
和
```
*Name
```
字段筛选）。在针对包含此章节的对象编写查询之前，请阅读此内容——这些约束无法从
```
fields
```
属性推导得出。
```
wsdl_segment
```
：架构定义（冗长——除非需要原始类型，否则跳过）
```
sub_types
```
和上述未列出的任何
```
snake_case
```
命名章节：特定对象的嵌套架构描述，仅当该对象的文档页面有匹配标题时存在——通过
```
sections
```
数组按对象发现这些章节

fields_columns

数组告诉你每个对象的

fields

条目包含哪些列——请按对象检查，不要假设固定结构。企业级sObject通常会添加

relationship_name

、

refers_to

和

relationship_type

；Tooling记录通常仅包含

type

、

properties

、

description

——但有相当一部分Tooling对象也包含

relationship_type

，因此不要将其视为企业级API专属。

relationship_type

值在源数据中也有拼写变体（例如

"Lookup"

"Look up"

）——请宽松比较（例如

.replace(" ", "").lower()

），不要精确匹配字符串。

类型字符串在不同对象中大小写不一致——不要假设单一大小写。同一概念会根据源文档页面的不同以多种大小写形式出现：

string

String

、

boolean

Boolean

、

dateTime

DateTime

datetime

。请对

type

值进行不区分大小写的比较（例如

.lower()

），不要使用

==

与单一大小写值匹配。除了常见的

string | reference | picklist

类型外，实际数据还包括

int

、

boolean

、

double

、

currency

、

date

、

dateTime

、

textarea

、

address

、

url

、

phone

、

email

、

time

、

anyType

、

base64

等——请将类型列表视为开放式的。

即使对象本身包含结构化的
type
/
properties
，字段也可能缺少这些信息——在得出数据缺失的结论之前，请检查
description
作为备用。由于每个对象的JSON都是从该对象自身的文档页面生成的，如果页面将字段的类型/属性以散文形式（

"Type: ... Properties: ... Description: ..."

）呈现为单个描述段落，而非单独的表格列，则会生成

type

properties

为空、散文内容填充到

description

中的

fields

条目。这种情况的原因多种多样（跨多个标准对象复用的通用模板页面，例如历史/共享/跟踪反馈的关联对象），可能影响一个字段到对象的所有字段——最坏情况下

fields_columns

可能仅包含

["description"]

。如果
type
/
properties
为空或
fields_columns
看起来异常简短，请检查
description
是否以
"Type: "
开头，并将其作为备用解析，然后再得出字段/对象无类型信息的结论。

选择列表的允许值有时会出现在
description
散文中——在假设它们不存在之前，请检查。没有

fields

条目包含结构化的

picklistValues

列表。选择列表的允许值是否在

description

中枚举（以

"Possible values are: ..."

开头，后跟值）完全取决于源文档页面是否为该特定字段枚举了这些值——很多会枚举，很多不会（例如由单独值集对象支持的组织可配置选择列表通常仅给出示例，如“例如New、Closed或Escalated”，而非完整列表）。当存在时，格式本身也不一致——有时是空格/逗号分隔的标记，有时是每行的

Value—explanation

破折号对——因此没有单一可靠的正则表达式；提取

"Possible values are:"

后的子字符串并逐案解析，不要假设每个选择列表都有可发现的值集。

字段的
description
可能引用关系（例如“这是一个依赖选择列表”、“此字段控制X”），但未命名或解析关系的另一端——企业级sObject自身的
fields
章节并不总是答案所在。此数据集的Tooling API层面记录了Salesforce的字段元数据对象（关于架构的架构，例如公开每个字段描述风格属性的对象），这些对象可能包含结构化属性——例如依赖选择列表的控制字段标识——而企业级sObject的文档页面从未明确命名这些属性。如果企业级字段的描述指向未解析的关系，请在得出数据不存在于本技能中的结论之前，检查Tooling层面的字段元数据对象是否能回答该问题。

给定对象的JSON可能包含上述常见列表之外的章节——请检查该对象自身的
sections
数组，不要假设是封闭集合。源文档页面上的任何额外

##

标题都会成为自己的

snake_case

命名章节（或者当转换器识别到它是不同的嵌套类型时，成为

sub_types

条目）。这些章节仅出现在文档恰好包含该标题的特定对象上——每个对象的架构描述负载，而非可忽略的垃圾内容。没有固定的所有可能额外章节名称的枚举；请通过

sections

按对象发现它们。

请参阅索引表获取完整的对象列表和每个对象的额外章节——文件约125 KB，因此请使用

grep -i "<ObjectName>"

进行单个查询，而非读取整个文件。

更多细节：实用的查询/DML示例、关系遍历模式和完整的章节术语表位于
references/usage_guide.md
中。仅在需要时使用
Read
工具加载此文件。

File Location

文件位置

Object JSON files are split by API surface:

text

assets/
├── enterprise_api/      # standard sObjects (SOQL/DML)
│   ├── Account.json
│   ├── Contact.json
│   └── ...
└── tooling_api/         # developer / diagnostics records
    ├── ApexClass.json
    ├── TraceFlag.json
    └── ...

Files are referenced relative to the skill root, e.g.

assets/enterprise_api/Account.json

assets/tooling_api/ApexClass.json

对象JSON文件按API层面拆分：

text

assets/
├── enterprise_api/      # 标准sObject（SOQL/DML）
│   ├── Account.json
│   ├── Contact.json
│   └── ...
└── tooling_api/         # 开发者/诊断记录
    ├── ApexClass.json
    ├── TraceFlag.json
    └── ...

文件相对于技能根目录引用，例如

assets/enterprise_api/Account.json

或

assets/tooling_api/ApexClass.json

。

Working Examples

实用示例

Runnable section-loading examples (each demonstrates: fields extraction, filterable-field lookup via

properties

, relationship traversal, the

fields

field_reference

dual catalog, and reading Tooling

supported_rest_api_http_methods

Python:

examples/python_section_loading.py

—

json.load()

with section extraction

JavaScript/Node.js:

examples/javascript_section_loading.js

—

JSON.parse()

with section extraction

Bash + jq:
```
examples/bash_section_loading.sh
```
—
```
jq
```
command-line JSON processing

See

examples/README.md

for usage and the property→SOQL/DML capability table.

可运行的章节加载示例（每个示例演示：字段提取、通过

properties

查询可筛选字段、关系遍历、

fields

与

field_reference

双目录、读取Tooling的

supported_rest_api_http_methods

）：

Python：

examples/python_section_loading.py

— 使用

json.load()

提取章节

JavaScript/Node.js：

examples/javascript_section_loading.js

— 使用

JSON.parse()

提取章节

Bash + jq：
```
examples/bash_section_loading.sh
```
— 使用
```
jq
```
命令行处理JSON

请参阅

examples/README.md

获取使用说明和属性→SOQL/DML能力对照表。

Query & DML Generation Requirements

查询与DML生成要求

When generating SOQL/SOSL or DML against these objects, follow these rules so the statement actually runs.

当针对这些对象生成SOQL/SOSL或DML时，请遵循以下规则以确保语句可正常运行。

Verify the field exists and its API name

验证字段存在性及其API名称

Look up the field first (both catalogs, atomic jq) and print the
field_lookup:
gate line — even for system fields you're sure about. See the Field-Existence Gate at the top of "How to Use This Skill". Field API names are case-insensitive to Salesforce but must resolve to a real field. Custom fields end in
```
__c
```
; custom relationships traverse with
```
__r
```
.
Do not invent fields. A guessed column produces
```
INVALID_FIELD: No such column 'X' on entity 'Y'
```
. If unsure, load the
```
fields
```
section and confirm.
Don't case-fold
fields
keys when matching. At least one object (
```
LoginEventLog
```
) has both
```
UserName
```
and
```
Username
```
as distinct real fields in the same
```
fields
```
dict — a lowercase/case-insensitive lookup would silently collide them. Match the exact key casing as given. These are two different columns holding potentially different data — they are NOT the same field that "resolves to whichever the platform picks." Select and filter each by its exact casing; do not describe them as interchangeable or say a query "resolves ambiguously," because the platform treats them as distinct fields.

首先查询字段（同时检查两个目录，使用原子jq命令）并打印
field_lookup:
检查行——即使是你确定的系统字段。请参阅“如何使用本技能”顶部的字段存在性检查部分。字段API名称对Salesforce不区分大小写，但必须解析为真实字段。自定义字段以
```
__c
```
结尾；自定义关系通过
```
__r
```
遍历。
不要凭空创建字段。猜测的列会导致
```
INVALID_FIELD: No such column 'X' on entity 'Y'
```
错误。如果不确定，请加载
```
fields
```
章节并确认。
匹配时不要对
fields
键进行大小写转换。至少有一个对象（
```
LoginEventLog
```
）的同一
```
fields
```
字典中同时存在
```
UserName
```
和
```
Username
```
两个不同的真实字段——小写/不区分大小写的查询会导致静默冲突。请完全匹配给定的键大小写。它们是两个不同的列，可能包含不同的数据——并非“平台会选择其中一个”的同一字段。请按精确大小写选择和筛选每个字段；不要将它们描述为可互换的，或说查询“解析模糊”，因为平台将它们视为不同的字段。

Respect field properties

尊重字段属性

The

properties

string on each field controls what you can do with it:

Filter → usable in a
```
WHERE
```
clause. A field without
```
Filter
```
cannot be filtered.
Sort → usable in
```
ORDER BY
```
.
Group → usable in
```
GROUP BY
```
.
Createable / Updateable → settable via
```
insert
```
/
```
update
```
DML. System and formula fields are read-only (no Create/Update) — writing them fails.
Nillable → may be null; a non-nillable field is required on insert.

This skill's
properties
string has no External ID flag —

upsert

requires a field marked External ID in the org, and that flag isn't captured by this data source (it only appears in Metadata API describe output, not the HTML docs this skill is built from). To find or set a field's External ID flag, use the Metadata API skill (

platform-metadata-api-context-get

) and check

CustomField

externalId

attribute — don't guess an upsert field from this skill's properties alone.

每个字段的

properties

字符串控制你可以对其执行的操作：

Filter → 可用于
```
WHERE
```
子句。没有
```
Filter
```
属性的字段无法被筛选。
Sort → 可用于
```
ORDER BY
```
。
Group → 可用于
```
GROUP BY
```
。
Createable / Updateable → 可通过
```
insert
```
/
```
update
```
DML设置。系统字段和公式字段为只读（无Create/Update属性）——写入这些字段会失败。
Nillable → 可为空；不可为空的字段在插入时为必填项。

本技能的
properties
字符串不包含外部ID标记——

upsert

需要组织中标记为外部ID的字段，而该标记未被此数据源捕获（仅出现在Metadata API描述输出中，而非本技能基于的HTML文档）。如需查找或设置字段的外部ID标记，请使用Metadata API技能（

platform-metadata-api-context-get

）并检查

CustomField

的

externalId

属性——不要仅凭本技能的属性猜测upsert字段。

Relationships (enterprise sObjects)

关系（企业级sObject）

For

reference

-type fields, the

relationship_name

column gives the parent relationship for SOQL traversal and

refers_to

names the target object(s):

sql

-- OwnerId (reference, relationship_name = Owner, refers_to = User)
SELECT Id, Owner.Name FROM Account
-- Custom lookup Foo__c traverses as Foo__r
SELECT Id, Foo__r.Name FROM My_Object__c

对于

reference

类型的字段，

relationship_name

列提供SOQL遍历的父关系，

refers_to

命名目标对象：

sql

-- OwnerId（参考类型，relationship_name = Owner，refers_to = User）
SELECT Id, Owner.Name FROM Account
-- 自定义查找字段Foo__c通过Foo__r遍历
SELECT Id, Foo__r.Name FROM My_Object__c

Tooling API vs Data API

Tooling API vs 数据API

Tooling records (

assets/tooling_api/

) are queried through the Tooling API endpoint (

/services/data/vXX.0/tooling/query

), not the regular Data API. Check

supported_soap_calls

supported_rest_api_http_methods

for what each record supports. Many Tooling objects are read-only.

Not for deployment. To author or edit
*-meta.xml
source (CustomObject, Flow, Profile, ...) use the Metadata API skill — the objects here are the runtime/queryable representation, not the deployable metadata form.

Tooling记录（

assets/tooling_api/

）通过Tooling API端点（

/services/data/vXX.0/tooling/query

）查询，而非常规数据API。请检查

supported_soap_calls

supported_rest_api_http_methods

以了解每个记录支持的操作。许多Tooling对象为只读。

不适用于部署场景。如需编写或编辑
*-meta.xml
源文件（CustomObject、Flow、Profile等），请使用Metadata API技能——此处的对象是运行时/可查询的表示形式，而非可部署的元数据形式。

Duplicate and Ambiguous Object Names

重复和模糊的对象名称

Several names exist in BOTH the Metadata API and here (ApexClass, ApexTrigger, CustomField, CustomObject, EmailTemplate, Layout, Profile, PermissionSet, RecordType, ValidationRule, Flow, ...). They mean different things:

This skill = the runtime/queryable record: fields you
```
SELECT
```
, filter, and (sometimes) write via the Data or Tooling API.
Metadata API skill = the
```
*-meta.xml
```
source form you author and deploy.

Resolve ambiguity with these signals:

"query", "SOQL", "SOSL", "DML", "insert/update/upsert", "what fields/columns", "filterable", "record", "runtime", "REST/SOAP" → this skill.
"authoring", "deploy", "retrieve",
```
package.xml
```
,
```
force-app/
```
,
```
sfdx
```
,
```
.meta.xml
```
, "blueprint/template" → Metadata API skill.
Tooling-specific: "Tooling API",
```
ApexCodeCoverage
```
,
```
EntityDefinition
```
,
```
TraceFlag
```
,
```
SymbolTable
```
, "code coverage", "compile errors", "debug log" → Tooling half of this skill (
```
assets/tooling_api/
```
).

If invoked directly by name with no other signal, default to the runtime data interpretation and disclose the assumption.

多个名称同时存在于Metadata API和本技能中（ApexClass、ApexTrigger、CustomField、CustomObject、EmailTemplate、Layout、Profile、PermissionSet、RecordType、ValidationRule、Flow等）。它们的含义不同：

本技能 = 运行时/可查询记录：可通过数据或Tooling API
```
SELECT
```
、筛选和（有时）写入的字段。
Metadata API技能 = 可编写和部署的
```
*-meta.xml
```
源形式。

通过以下信号解决歧义：

“查询”、“SOQL”、“SOSL”、“DML”、“insert/update/upsert”、“哪些字段/列”、“可筛选”、“记录”、“运行时”、“REST/SOAP” → 本技能。
“编写”、“部署”、“检索”、
```
package.xml
```
、
```
force-app/
```
、
```
sfdx
```
、
```
.meta.xml
```
、“蓝图/模板” → Metadata API技能。
Tooling特定：“Tooling API”、
```
ApexCodeCoverage
```
、
```
EntityDefinition
```
、
```
TraceFlag
```
、
```
SymbolTable
```
、“代码覆盖率”、“编译错误”、“调试日志” → 本技能的Tooling部分（
```
assets/tooling_api/
```
）。

如果仅通过名称直接调用且无其他信号，请默认使用运行时数据解释并披露此假设。

Troubleshooting

故障排除

File Not Found

文件未找到

File names are case-sensitive PascalCase matching the object API name (
```
Account.json
```
,
```
ApexClass.json
```
), no separators.
Check the correct folder: enterprise sObjects in
```
assets/enterprise_api/
```
, Tooling records in
```
assets/tooling_api/
```
. A name can exist in only one, or in both with different fields.
Before declaring "not found", search the index table (it lists every object name in the corpus) with a targeted grep rather than reading the whole ~125 KB file:
```
grep -i "<ObjectName>" references/data_and_tooling_index_table.md
```
. Match case-insensitively and allow for near-misses (spacing, plural, minor spelling) before concluding the object is absent. Read the full file only for a broad survey.

文件名区分大小写，采用PascalCase格式，与对象API名称匹配（
```
Account.json
```
、
```
ApexClass.json
```
），无分隔符。
检查正确的文件夹：企业级sObject位于
```
assets/enterprise_api/
```
，Tooling记录位于
```
assets/tooling_api/
```
。名称可能仅存在于一个文件夹中，或同时存在于两个文件夹中但字段不同。
在声明“未找到”之前，请使用定向grep搜索索引表（它列出了语料库中的所有对象名称），而非读取整个约125 KB的文件：
```
grep -i "<ObjectName>" references/data_and_tooling_index_table.md
```
。进行不区分大小写的匹配，并允许近似匹配（空格、复数、拼写差异），然后再得出对象不存在的结论。仅在进行广泛调查时才读取整个文件。

INVALID_FIELD / No such column

INVALID_FIELD / 无此列

The field is not on that object, or you used the wrong API name. Load the
```
fields
```
section and confirm the exact name (custom fields end in
```
__c
```
).
The field exists but lacks the needed property: filtering a non-
```
Filter
```
field, sorting a non-
```
Sort
```
field, or writing a read-only (no
```
Create
```
/
```
Update
```
) field all fail. Check the
```
properties
```
string.

字段不在该对象上，或你使用了错误的API名称。加载
```
fields
```
章节并确认确切名称（自定义字段以
```
__c
```
结尾）。
字段存在但缺少所需属性：筛选非
```
Filter
```
字段、排序非
```
Sort
```
字段或写入只读（无
```
Create
```
/
```
Update
```
属性）字段都会失败。请检查
```
properties
```
字符串。

Relationship query fails

关系查询失败

Use
```
relationship_name
```
(not the id field) to traverse:
```
Owner.Name
```
, not
```
OwnerId.Name
```
. Custom lookups traverse with
```
__r
```
.
Confirm
```
refers_to
```
— polymorphic fields (e.g.
```
WhoId
```
,
```
WhatId
```
) refer to multiple objects and need
```
TYPEOF
```
or the correct relationship.

使用
```
relationship_name
```
（而非ID字段）进行遍历：
```
Owner.Name
```
，而非
```
OwnerId.Name
```
。自定义查找字段通过
```
__r
```
遍历。
确认
```
refers_to
```
——多态字段（例如
```
WhoId
```
、
```
WhatId
```
）引用多个对象，需要
```
TYPEOF
```
或正确的关系。

Tooling query returns nothing / errors

Tooling查询无返回结果/报错

Tooling objects must be queried against the Tooling API endpoint (
```
/tooling/query
```
), not the standard Data API. Verify with
```
supported_rest_api_http_methods
```
/
```
supported_soap_calls
```
.

Tooling对象必须针对Tooling API端点（
```
/tooling/query
```
）查询，而非标准数据API。请通过
```
supported_rest_api_http_methods
```
/
```
supported_soap_calls
```
验证。

Field is in wsdl_segment but not fields

字段存在于wsdl_segment但不存在于fields中

Complex nested types have their sub-fields in
```
wsdl_segment
```
. Pull just the matching
```
complexType
```
with
```
jq -r '.wsdl_segment' file.json | grep -A 30 'complexType name="Foo"'
```
instead of loading the whole segment.

复杂嵌套类型的子字段存在于
```
wsdl_segment
```
中。请使用
```
jq -r '.wsdl_segment' file.json | grep -A 30 'complexType name="Foo"'
```
提取匹配的
```
complexType
```
，而非加载整个片段。

Common Objects

常见对象

Enterprise / Data API (SOQL + DML)

企业级/数据API（SOQL + DML）

Account: Represents an individual account, which is an organization or person involved with your business (such as customers, competitors, and partners).
Contact: Represents a contact, which is a person associated with an account.
Opportunity: Represents an opportunity, which is a sale or pending deal.
Lead: Represents a prospect or lead.
Case: Represents a case, which is a customer issue or problem.
User: Represents a user in your organization.
Task: Represents a business activity such as making a phone call or other to-do items.
Event: Represents an event in the calendar.

Account：代表单个账户，即与你的业务相关的组织或个人（例如客户、竞争对手和合作伙伴）。
Contact：代表联系人，即与账户关联的个人。
Opportunity：代表销售机会，即待完成的销售或交易。
Lead：代表潜在客户或线索。
Case：代表客户案例，即客户的问题或诉求。
User：代表你的组织中的用户。
Task：代表业务活动，例如打电话或其他待办事项。
Event：代表日历中的事件。

Tooling API (developer records)

Tooling API（开发者记录）

ApexClass: Represents the saved copy of an Apex class.
ApexTrigger: Represents the saved copy of an Apex trigger.
ApexCodeCoverageAggregate: Represents aggregate code coverage test results for an Apex class or trigger.
TraceFlag: Represents a trace flag that triggers an Apex debug log at the specified logging level.
EntityDefinition: Provides row-based access to metadata about standard and custom objects.

ApexClass：代表Apex类的已保存副本。
ApexTrigger：代表Apex触发器的已保存副本。
ApexCodeCoverageAggregate：代表Apex类或触发器的聚合代码覆盖率测试结果。
TraceFlag：代表跟踪标记，可在指定日志级别触发Apex调试日志。
EntityDefinition：提供对标准和自定义对象元数据的基于行的访问。",