generating-custom-object

Use this skill when users need to create, generate, or validate Salesforce Custom Object metadata. Trigger when users mention custom objects, creating objects,…

installs

stars

karma

view original SKILL.md from skills.shclick to expand

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 (.object-meta.xml file). The agent must verify these constraints before outputting XML to prevent Metadata API deployment errors.

File extension: .object-meta.xml

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

<label>
Required
Singular UI name

<pluralLabel>
Required
Plural UI name

<sharingModel>
Required
See Sharing Model Rules below

<deploymentStatus>
Required
Always set to Deployed

<nameField>
Required
Primary record identifier (requires <label> and <type>)

<visibility>
Required
Always set to Public

Sharing Model Rules

Default: Set <sharingModel> to ReadWrite.

Exception: If this object contains a Master-Detail relationship field, <sharingModel> MUST be ControlledByParent.

Decision Logic:

IF object has NO Master-Detail field → use ReadWrite

IF object has Master-Detail field → use ControlledByParent

IF a Master-Detail field is being added to an existing child object → that existing object's <sharingModel> must also be updated to ControlledByParent

❌ INCORRECT — Will cause error: Cannot set sharingModel to ReadWrite on a CustomObject with a MasterDetail relationship field

<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:

<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 <displayFormat> (e.g., INV-{0000}) and <startingNumber>1</startingNumber>

Text Name Field Example:

<nameField>
  <label>Project Name</label>
  <type>Text</type>
</nameField>

AutoNumber Name Field Example:

<nameField>
  <label>Invoice Number</label>
  <type>AutoNumber</type>
  <displayFormat>INV-{0000}</displayFormat>
  <startingNumber>1</startingNumber>
</nameField>

B. Object Description

<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:

Position_Candidate__c (links Position and Candidate)

Job_Application__c (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 false.

Scenario A: User-Facing Objects (Apps, Trackers, Business Entities)

Trigger: The object is intended for direct user interaction

Action: Set <enableSearch>, <enableReports>, <enableActivities>, and <enableHistory> to true

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
Select, From, Where, Limit, Order, Group

System
User, External, View, Type

Temporal
Date, Number

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 <fullName> tag at the root of the .object-meta.xml file. The API name is derived from the filename.

❌ INCORRECT:

<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
  <fullName>Vehicle__c</fullName>  <!-- WRONG: Remove this -->
  <label>Vehicle</label>
</CustomObject>

✅ CORRECT:

<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 __c (unlike custom fields)

❌ INCORRECT:

<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:

<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 __c
Start_Date__c

Validation Rules
No suffix
Require_Start_Date

Custom Objects
Ends with __c
Vehicle__c

5. Verification Checklist

Before generating the Custom Object XML, verify:

Syntactic Checks

 Are both <label> and <pluralLabel> present?

 Is <deploymentStatus> set to Deployed?

 Is <visibility> set to Public?

 Does <nameField> include both <label> and <type>?

 If <type> is AutoNumber, are <displayFormat> and <startingNumber> included?

Sharing Model Check (Critical)

 Does this object have a Master-Detail relationship field?

If YES → <sharingModel> MUST be ControlledByParent

If NO → <sharingModel> should be ReadWrite

Constraint Checks

 Is the API name free of reserved words?

 Are there 2 or fewer Master-Detail relationships?

 Is <fullName> absent from the XML root?

Validation Rule Checks (if applicable)

 Do validation rule names NOT end with __c?

 Do validation rule names follow alphanumeric + underscore pattern?

Architectural Checks

 Is <description> present with a meaningful summary?

 Are <enableSearch> and <enableReports> set to true if user-facing?

 Does the filename match the intended API name?

don't have the plugin yet? install it then click "run inline in claude" again.

converted specification-heavy original into structured implexa format with explicit decision points for sharing model and feature enablement, added edge cases (reserved words, m-d relationship limits, validation rule naming), documented all inputs including org auth and conditional elements, and added comprehensive outcome signals for validation and deployment.

intent

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, or troubleshoot deployment errors related to custom objects. trigger when users mention custom objects, creating objects, or salesforce schema changes. the skill outputs valid .object-meta.xml files that pass salesforce metadata api validation without errors.

inputs

salesforce org connection: valid org auth (via salesforce cli or oauth token). env var: SALESFORCE_AUTH_URL or SFDX_INSTANCEURL.
object intent: what the object tracks or manages (e.g., "invoices", "project tasks", "candidate positions").
name field type: text (default for human names) or autonumber (for transaction ids, tickets, logs).
master-detail relationships: list of any m-d fields the object will contain, including parent object names.
user-facing vs system-facing: is this object for end users (apps, dashboards) or backend (junctions, logs)?
validation rules (optional): list of business logic constraints that need enforcement.
existing object metadata (if updating): current .object-meta.xml file to check for sharing model conflicts.

procedure

validate object api name
- input: proposed api name (e.g., Vehicle__c).
- check against reserved word list (soql: select, from, where, limit, order, group; system: user, external, view, type; temporal: date, number).
- if name contains reserved word, reject and request alternative.
- output: approved api name or error message.
determine sharing model
- input: list of master-detail relationship fields (if any).
- if object has zero m-d fields, set <sharingModel> to ReadWrite.
- if object has one or more m-d fields, set <sharingModel> to ControlledByParent.
- output: sharing model value (ReadWrite or ControlledByParent).
generate name field xml
- input: name field type (text or autonumber).
- if text: generate <nameField> with <label> and <type>Text</type>.
- if autonumber: generate <nameField> with <label>, <type>AutoNumber</type>, <displayFormat> (e.g., INV-{0000}), and <startingNumber>1</startingNumber>.
- output: complete name field xml block.
determine feature enablement
- input: object classification (user-facing or system-facing).
- if user-facing: include <enableSearch>true</enableSearch>, <enableReports>true</enableReports>, <enableActivities>true</enableActivities>, <enableHistory>true</enableHistory>.
- if system-facing: omit all feature tags (defaults to false, keeps xml lean).
- output: feature tags or empty string.
compose object description
- input: object intent from user.
- if intent is clear, generate professional summary (e.g., "tracks and manages invoices across the organization").
- if intent is vague, use template: "Object used to track and manage [intent] within the organization."
- output: <description> element.
validate validation rule names
- input: list of validation rule fullNames.
- check each name: alphanumeric + underscore only, starts with letter, does not end with underscore or __c, no consecutive underscores.
- if any name violates rules, reject and request correction.
- output: approved validation rule names or error list.
assemble custom object xml
- input: all components from steps 1-6 (api name, sharing model, name field, description, features, validation rules).
- do not include <fullName> at root level (api name comes from filename).
- include xmlns attribute: xmlns="http://soap.sforce.com/2006/04/metadata".
- required root elements: <label>, <pluralLabel>, <sharingModel>, <deploymentStatus>Deployed</deploymentStatus>, <visibility>Public</visibility>, <nameField>.
- output: complete .object-meta.xml as string.
verify master-detail relationship count
- input: all m-d field definitions.
- count m-d relationships; if more than 2, flag error and suggest converting third+ to lookup fields.
- output: pass/fail with reasoning.
write metadata file
- input: generated xml, filename (e.g., Vehicle__c.object-meta.xml).
- write to file in standard salesforce metadata directory structure: force-app/main/default/objects/{ApiName}/{ApiName}.object-meta.xml.
- output: file path and confirmation.
run deployment validation (optional, requires org connection)
- input: salesforce org auth, generated .object-meta.xml file.
- execute sf metadata deploy or validate-only check against org.
- capture any validation errors (syntax, naming, relationship constraints).
- output: validation report or deployment log.

decision points

if object has master-detail relationship fields, then set sharingModel to ControlledByParent; else set to ReadWrite. this is critical. salesforce will reject ReadWrite sharing on any object containing m-d fields.

if updating an existing child object and adding a master-detail field, then that object's sharingModel must also change to ControlledByParent; else existing child objects with no m-d fields stay as ReadWrite. this prevents orphaned schema states.

if object is user-facing (end users interact directly), then enable search, reports, activities, and history; else omit these tags for system-facing objects (junctions, background logs). this keeps ui clean and xml lean.

if name field type is autonumber, then include displayFormat and startingNumber; else name field is text and requires only label and type. auto number fields must have a format pattern.

if validation rule names end with __c or violate naming rules, then reject the rule and request correction; else allow the rule in the metadata. this prevents deployment failures.

if api name contains reserved words (select, from, where, limit, order, group, user, external, view, type, date, number), then reject the name and ask for alternative; else proceed. reserved words break soql and metadata parsing.

if master-detail relationship count exceeds 2, then reject the schema design and suggest converting third+ to lookup fields; else allow the object. salesforce enforces a hard limit of 2 m-d relationships per object.

output contract

file format: xml text, utf-8 encoding.
file extension: .object-meta.xml.
file location: force-app/main/default/objects/{ApiName}/{ApiName}.object-meta.xml (standard salesforce dx structure). if no path provided, use current directory.
xml structure: well-formed, valid against salesforce custom object schema.
required elements present: label, pluralLabel, sharingModel, deploymentStatus (Deployed), visibility (Public), nameField with label and type, description.
conditional elements: enableSearch, enableReports, enableActivities, enableHistory (user-facing objects only).
no fullName at root: api name derived from filename, not embedded in xml.
validation rules (if present): proper naming convention (no __c suffix, alphanumeric + underscore, starts with letter).

outcome signal

file exists: user can run ls -la force-app/main/default/objects/{ApiName}/{ApiName}.object-meta.xml and confirm file is present and non-empty.
xml validity: user can parse the file with an xml validator or run sf metadata validate -m CustomObject and see zero syntax errors.
deployment success (if deployed): user runs sf metadata deploy and sees deployment status "Done" with no errors related to this object.
schema appears in org: user logs into salesforce, navigates to Setup > Object Manager, and sees the new custom object with correct label, plural label, name field type, and sharing model.
features enabled correctly: if user-facing, search and reports tabs are active on the object page; if system-facing, these are hidden.
no reserved word conflicts: object api name is accepted by metadata api without "reserved word" or "invalid api name" errors.
validation rules active: if rules included, user can view them in object setup page with correct names and formulas, no naming errors.