/field-service-data-capture-form-deployer-configure

name: field-service-data-capture-form-deployer-configure
description: "Assemble a Data Capture Flow from a JSON spec and deploy it to a connected Field Service org via the Tooling Flow sObject (JSON Metadata, no XML). Use when given a data-capture spec JSON and asked to build or deploy a DataCaptureFlow."
user-invocable: false
metadata:
  version: "1.0"
  domains: ["Field Service"]

Build a Data Capture Form (Field Service Mobile)

This skill takes an intermediate JSON spec and produces a deployed Salesforce Flow with `processType=DataCaptureFlow`. It assumes the spec is already correct and approved — confirmation with the user happens upstream in the design skills.

> **Runtime contract:** every org interaction in this skill is a REST call > dispatched through the Codey runtime (`dispatch` locally / the hosted > Headless 360 MCP in shared surfaces). This skill has **no dependency on the > execution environment** — no `sf` CLI, no shell scripts, no local Python, no > temp files. Auth probes, record reads, and record writes are single REST > calls; the Flow XML is authored by the agent inline from the reference docs. > Do not shell out.

Input contract

A JSON file matching the schema in [reference/field-types.md](reference/field-types.md) and (optionally) [reference/post-screen-automation.md](reference/post-screen-automation.md). Canonical examples:

• [examples/sample-spec.json](examples/sample-spec.json) — minimal screens-only flow.
• [examples/inventory-transfer-spec.json](examples/inventory-transfer-spec.json) — full example with Repeater, Radio, visibility, decision, lookups, loop, and record-create.

Required top-level keys: `formTitle`, `formType`, `screens`. Optional: `postScreen`.

Output

A Data Capture Flow created in the org via a single Tooling API call — `POST /services/data/vXX.0/tooling/sobjects/Flow` with a JSON `Metadata` body (no `.flow-meta.xml`, no zip, no SFDX project). The flow is created in `Draft` status and the user activates it themselves in Flow Builder.

Workflow

1. Verify org auth

Confirm the connected org is reachable with a cheap auth probe — dispatch `SELECT Id FROM Organization LIMIT 1` (`GET /services/data/vXX.0/query`):

• 2xx with `totalSize=1` → the session token is live; continue.
• 401/403 → the org needs re-authentication. Surface that to the user and **stop**; do not deploy. (The Codey runtime resolves and refreshes the connected org — this skill does not manage org aliases.)

2. Pick a Flow API name

If the design skill already supplied `<FlowApiName>`, use it. Otherwise derive from `formTitle`: PascalCase, no spaces, must match `^[A-Z][A-Za-z0-9_]*$`. If the title can't be coerced, ask the user.

3. Build the Flow Metadata JSON

Assemble the flow's `Metadata` object **inline** from the spec — the Tooling `Flow` sObject takes a JSON `Metadata` blob, so there is no XML to compile and no converter to run. Follow the JSON shape and field mappings in [reference/flow-metadata-json.md](reference/flow-metadata-json.md) and [reference/field-types.md](reference/field-types.md).

Notes:

• The JSON `Metadata` is the exact same shape the Tooling `Flow` GET returns (`GET /tooling/sobjects/Flow/{id}` → `Metadata`), so you can retrieve a known-good sibling flow as a live reference before composing.
• **Dedupe choices** across the entire flow — two fields with `["Good","Fair","Poor"]` share the same three entries in the top-level `choices` array.
• Repeater children are nested as `fields` entries inside the parent Repeater field.
• `Signature`, `UploadFile`, `UploadImage`, and `Images` auto-wire `parentRecordId` / `recordId` to the standard DataCaptureFlow input variables. They deploy as functional components, no Flow Builder cleanup required.
• `Lookup` requires a `lookupObject` spec key; without it, emit the labeled `dcTextInput` placeholder. `FileView` requires a `fileName`; same fallback. Collect any such fallbacks and surface them in step 5.
• Self-check before deploying: `processType` is `DataCaptureFlow`, `environments` includes `Offline`, and the three input variables (`parentObjectType`, `parentRecordId`, `recordId`) are present.

4. Deploy to org

Create the flow with a single Tooling API call — dispatch `POST /services/data/vXX.0/tooling/sobjects/Flow` with body:

{
  "FullName": "<FlowApiName>",
  "Metadata": { "processType": "DataCaptureFlow", "environments": ["Offline"], "label": "...", "screens": [ ... ], "choices": [ ... ], "variables": [ ... ], "status": "Draft" }
}

• `FullName` is the Flow API name; `Metadata` is the object you assembled in step 3.
• A 201 with `success: true` returns the new Flow version id. `Status` stays `Draft` (set `Metadata.status: "Active"` only if the user asked to activate on create — the default is Draft so the user reviews in Flow Builder first).
• On a 400, the response body's `message` carries the Flow validation error — diagnose against step 5's failure table.

5. Report back

On success:

• Look up the FlowDefinition Id with a Tooling API query — dispatch `GET /services/data/vXX.0/tooling/query` with `SELECT Id, ActiveVersionId FROM FlowDefinition WHERE DeveloperName = '<FlowApiName>'`.
• Print a clickable Flow Builder URL: `<instanceUrl>/builder_platform_interaction/flowBuilder.app?flowId=<id>`.
• List screens, total field count, and any fallback fields (Lookup with no `lookupObject`, FileView with no `fileName`) the user needs to wire up in Flow Builder.
• Print the direct flow-launch URL: `<instanceUrl>/flow/<FlowApiName>` — the fastest validation path that bypasses QuickActions, layouts, and the Forms tab.

On failure (the `POST` returned a 400 — read the error from the response body's `message`):

• If `Cannot find component 'runtime_service_fieldservice:dcXxx'` → org doesn't have Field Service enabled (or the component name is wrong). Surface the exact error and stop.
• For Flow validation errors, the cause is usually a pattern listed in the prohibited-pa