/field-service-sobject-create-configure

name: field-service-sobject-create-configure
description: "Headless 360 REST API deployment step for creating sObject records. Handles describe-based field discovery, required-field derivation, entity-relationship ordering, and composite graph transactions. Use this skill when a designer skill (or a user directly) needs to create sObject records after design confirmation, including non-setup sObject creation."
user-invocable: false
metadata:
  version: "1.0"
  domains: ["Field Service"]
  cliTools:
    - tool: ["sf"]
      semver: ">=2.0.0"

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: true` at the top level. A `CANNOT_INSERT_UPDATE_ACTIVATE_ENTITY` on 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: ``referenceId`s used with `@{...}` MUST refer to a record earlier in the same graph. Wrong ordering surfaces as `INVALID_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

| Operation | Purpose | Status | Call | Depends on | |-----------|---------|--------|------|------------| | `describe-sobject` | read | — | `GET /services/data/v67.0/sobjects/{SObjectName}/describe` | — | | `query-existing-records` | read | — | `GET /services/data/v67.0/query` | `describe-sobject` | | `create-sobject-record` | write | — | `POST /services/data/v67.0/sobjects/{SObjectName}` | `describe-sobject` | | `composite-graph-create` | write | — | `POST /services/data/v67.0/composite/graph` | `describe-sobject` | | `update-sobject-record` | write | — | `PATCH /services/data/v67.0/sobjects/{SObjectName}/{Id}` | `create-sobject-record` | | `delete-sobject-record` |