When to Use This Skill
Use this skill when you need to:
- Create new custom objects
- Generate custom object metadata XML
- Configure object sharing and security settings
- Set up object features and capabilities
- Troubleshoot deployment errors related to custom objects
Specification
1. Overview and Purpose
This document defines the mandatory constraints for generating CustomObject metadata XML (
file). The agent must verify these constraints before outputting XML to prevent Metadata API deployment errors.
2. Syntactic Essentials (Tier 1)
The following constraints must be true for the XML body to deploy successfully.
Note: The API Name (fullName) is NOT a tag; it is the filename (e.g.,
Vehicle__c.object-meta.xml
).
Required Elements
| Element | Requirement | Notes |
|---|
| Required | Singular UI name |
| Required | Plural UI name |
| Required | See Sharing Model Rules below |
| Required | Always set to |
| Required | Primary record identifier (requires and ) |
| Required | Always set to |
Sharing Model Rules
Exception: If this object contains a Master-Detail relationship field,
MUST be
.
Decision Logic:
- IF object has NO Master-Detail field → use
- IF object has Master-Detail field → use
- IF a Master-Detail field is being added to an existing child object → that existing object's must also be updated to
❌ INCORRECT — Will cause error:
Cannot set sharingModel to ReadWrite on a CustomObject with a MasterDetail relationship field
xml
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
<label>Order Line Item</label>
<pluralLabel>Order Line Items</pluralLabel>
<sharingModel>ReadWrite</sharingModel> <!-- WRONG: Object has a M-D field -->
<deploymentStatus>Deployed</deploymentStatus>
</CustomObject>
✅ CORRECT:
xml
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
<label>Order Line Item</label>
<pluralLabel>Order Line Items</pluralLabel>
<sharingModel>ControlledByParent</sharingModel> <!-- CORRECT -->
<deploymentStatus>Deployed</deploymentStatus>
</CustomObject>
3. Smart Defaults & Decision Logic (Tier 2)
The agent must choose which features to enable based on the object's intended use case.
A. The Name Field Decision
| Type | When to Use | Additional Requirements |
|---|
| Text | Default for human-named entities (Projects, Locations, Teams) | None |
| AutoNumber | Use for transactions, logs, or IDs (Invoices, Requests, Tickets) | Must include (e.g., ) and <startingNumber>1</startingNumber>
|
Text Name Field Example:
xml
<nameField>
<label>Project Name</label>
<type>Text</type>
</nameField>
AutoNumber Name Field Example:
xml
<nameField>
<label>Invoice Number</label>
<type>AutoNumber</type>
<displayFormat>INV-{0000}</displayFormat>
<startingNumber>1</startingNumber>
</nameField>
B. Object Description
: Mandatory. Every object must contain a professional summary.
If the intent is vague, generate a summary:
"Object used to track and manage [Intent] within the organization."
C. Junction Object Naming
If the object is a many-to-many link between two parents, name the object by combining the two parent entities to ensure the schema remains intuitive.
Examples:
- (links Position and Candidate)
- (links Job and Application)
D. Feature Enablement (Clean XML)
To maintain "Clean XML," only include optional tags when deviating from the Salesforce platform default of
.
Scenario A: User-Facing Objects (Apps, Trackers, Business Entities)
- Trigger: The object is intended for direct user interaction
- Action: Set , , , and to
Scenario B: System-Facing Objects (Junctions, Background Logs)
- Trigger: The object exists for technical associations or background data
- Action: Omit these tags to keep the UI clean and the XML lean
4. Critical Constraints & Common Failures
Reserved Words
Never use reserved words as API names for Custom Objects or Custom Fields:
| Category | Reserved Words (Do Not Use as API Names) |
|---|
| SOQL/SQL | , , , , , |
| System | , , , |
| Temporal | , |
Relationship Cap
Do not create more than 2 Master-Detail relationships for a single object. If a third relationship is required, use a Lookup instead.
XML Root Element
Do NOT include the
tag at the root of the
file. The API name is derived from the filename.
❌ INCORRECT:
xml
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
<fullName>Vehicle__c</fullName> <!-- WRONG: Remove this -->
<label>Vehicle</label>
</CustomObject>
✅ CORRECT:
xml
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
<label>Vehicle</label>
<!-- fullName comes from filename: Vehicle__c.object-meta.xml -->
</CustomObject>
Validation Rule Naming Convention
Validation rule names follow different conventions than custom fields.
Rules:
- Must contain only alphanumeric characters and underscores
- Must begin with a letter
- Cannot end with an underscore
- Cannot contain two consecutive underscores
- Must NOT end with (unlike custom fields)
❌ INCORRECT:
xml
<validationRules>
<fullName>Require_Start_Date__c</fullName> <!-- WRONG: Has __c suffix -->
<active>true</active>
<errorMessage>Start Date is required.</errorMessage>
<formula>ISBLANK(Start_Date__c)</formula>
</validationRules>
Error: The validation name can only contain alphanumeric characters, must begin with a letter, cannot end with an underscore...
✅ CORRECT:
xml
<validationRules>
<fullName>Require_Start_Date</fullName> <!-- CORRECT: No __c suffix -->
<active>true</active>
<errorMessage>Start Date is required.</errorMessage>
<formula>ISBLANK(Start_Date__c)</formula>
</validationRules>
Naming Pattern Reference:
| Metadata Type | Naming Pattern | Example |
|---|
| Custom Fields | Ends with | |
| Validation Rules | No suffix | |
| Custom Objects | Ends with | |
5. Verification Checklist
Before generating the Custom Object XML, verify:
Syntactic Checks
Sharing Model Check (Critical)
Constraint Checks
Validation Rule Checks (if applicable)
Architectural Checks