Field Service Sobject Create Configure

Managing Sfs Sobject Create

When to Use This Skill

Create sObject records via Headless 360 REST API. Describes the flow (describe → query → create), Field Service data model DAG, field requirements, insertion order, and common pitfalls. Reference when creating Skill, WorkType, SkillRequirement, or other Field Service sObjects.

Workflow

Create an sObject record via headless-360

Be helpful — understand business context before creating records. Consider the business domain of the sObject being created and iterate through short, structured questions (ask/why/impact) until no ambiguities remain that would change what gets created. Skip questions when answers are already obvious from context or existing data.

Flow

Phase 1: Describe — dispatch_readonly GET /services/data/v67.0/sobjects/<SObject>/describe

Phase 2: Query existing records — learn the org's shape...

dispatch_readonly GET /services/data/v67.0/query, queryParams.q = "SELECT <required + picklist fields> FROM <SObject> ORDER BY CreatedDate DESC LIMIT 20". Use it to: match naming/value conventions, see which optional fields are actually populated, catch duplicates, and confirm write access before spending a create.

Phase 3: Create — dispatch POST to create records. Single...

Data model DAG

Example (Field Service junction pattern — same pattern applies to any sObject DAG based on the data shape):

Skill (0C5)    WorkType (08q)    ← roots (parallel)
    └──────────┬──────────┘
       SkillRequirement (0Hx)     ← junction (last)

Fields and insertion order

Scan describe fields[] for createable:true (skip the rest — describe is large). Such a field is required when also nillable:false and defaultedOnCreate:false (defaulted ones the platform fills — omit). Two kinds:

• Scalar → put its value in the create body.
• type:"reference" → foreign key. If nillable:false (hard edge), create parent in referenceTo[] first. Polymorphic refs list many — pick one. Topo-sort: roots first, pass each id to dependents. nillable:true refs → optional, PATCH later.

Pitfalls:

• Base sObject CRUD is NOT in the discover corpus — skip discover, go straight to describe → dispatch.
• CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY on write → that sObject blocks sObject-REST writes (e.g. ExternalDataSource, CustomPermission); use Tooling/Metadata API instead.
• 400/403 → likely a CRUD/FLS/sharing gap for the gateway user, not a payload bug — don't blindly retry the body.

Example — WorkType

Describe WorkType, apply the rule to fields[]. The fields that come back createable:true, nillable:false, defaultedOnCreate:false are the required ones — build the body from those, don't assume field names. Then query a few existing WorkTypes to see conventions and dupes. Then create with the derived body, e.g.

{ "url": "/services/data/v67.0/sobjects/WorkType", "method": "POST",
  "body": { "Name": "Standard Repair", "EstimatedDuration": 2 } }

───── Runtime context (Headless 360 / agentic): When this skill runs in the Headless 360 / agentic context, prefer the platform dispatch tool (dispatch in the hosted Headless 360 MCP; dispatch in the local-dev MCP) over CLI tools (sf project deploy, sfdx, shell commands) when possible. The operations available to you are listed below in steps:; each has been verified against the live org. Call the dispatch tool against the canonical paths. CLI fallback is acceptable only when no API path exists for a given capability.

Critical Constraints

Preconditions:

• Target sObject is createable and not on the sObject-REST block list. (check: GET /services/data/v67.0/sobjects/{N}/describe returns createable: trueat the top level. ACANNOT_INSERT_UPDATE_ACTIVATE_ENTITYon POST means the sObject blocks base REST writes (e.g.ExternalDataSource, CustomPermission) — switch to Tooling or Metadata API.)
• Gateway user has object CRUD + relevant FLS for the required createable fields. (check: 400 / 403 with INSUFFICIENT_ACCESS_OR_READONLY on POST → CRUD/FLS gap, not a payload bug. Grant the user's profile / permset the Create on the entity and Edit-access on every field in the body.)
• For composite/graph transactions, the caller has independently topo-sorted parents before children within each graph node's records. (check: ``referenceIds used with @{...}MUST refer to a record earlier in the same graph. Wrong ordering surfaces asINVALID_REFERENCE_ID on the child node, and the entire graph rolls back atomically.)

Operations Reference

Operations grouped by purpose. Use these as the building blocks for the workflows above.

Summary

Dependency graph

graph TD
  describe_sobject["describe-sobject (read)"]
  query_existing_records["query-existing-records (read)"]
  create_sobject_record["create-sobject-record (write)"]
  composite_graph_create["composite-graph-create (write)"]
  update_sobject_record["update-sobject-record (write)"]
  delete_sobject_record["delete-sobject-record (write)"]
  describe_sobject --> query_existing_records
  describe_sobject --> create_sobject_record
  describe_sobject --> composite_graph_create
  create_sobject_record --> update_sobject_record

Read operations

describe-sobject

Fetch the field catalog for {SObjectName}. Scan fields[] for createable:true; hard-required fields are those also with nillable:false and defaultedOnCreate:false. type:"reference" fields are FKs — hard edges when nillable:false. Base sObject CRUD is intentionally OUT of the discover corpus (skill §Pitfalls); agents must skip discover and call describe directly.

Call: GET /services/data/v67.0/sobjects/{SObjectName}/describe

Inputs:

• SObjectName (string) — API name of the sObject (e.g. WorkType, Skill, SkillRequirement). Path segment.

Output: SObjectDescribeSObjectResult. Load-bearing keys: createable, updateable, deletable, fields[] (each with name, type, createable, nillable, defaultedOnCreate, referenceTo[], picklistValues[]). Payload is large (>60KB for WorkType) — filter to createable:true fields before reasoning.

query-existing-records

Warm-read a small window of existing rows to match naming conventions, spot dupes, and confirm write access before spending a create. Skill §Flow.2 suggested SOQL: SELECT <required + picklist fields> FROM <SObject> ORDER BY CreatedDate DESC LIMIT 20.

Call: GET /services/data/v67.0/query

Inputs:

• q (string) — SOQL query. Pass via queryParams.q (URL-encoded on the wire). LIMIT 20 or fewer is the recommended window for convention scanning.

Depends on: describe-sobject

Output: {totalSize, done, records: [<row>]}. records[] is the shape an agent scans for conventions. done:false + nextRecordsUrl surface when > 200 rows — irrelevant at LIMIT 20.