Field Service Data Capture Reference Configure

Querying Fs Data Capture Reference

When to Use This Skill

Build, edit, and deploy Salesforce Data Capture Flows (processType DataCaptureFlow) — Field Service mobile / offline forms. Use when authoring flow-meta.xml with runtime_service_fieldservice:dc* components, Repeater loops (.AllItems), master-detail child record persistence, visual polish (gradient banners, progress bars, callouts), supporting objects with FLS/permsets, debugging DataCaptureFlow deploy errors, or troubleshooting why a deployed form doesn't appear on the FSL Mobile Forms tab (DDC/WorkPlan OWD + AssignedResource sharing prerequisites).

Workflow

Salesforce Data Capture Flow Skill

Build, edit, and deploy Salesforce Flows with processType: DataCaptureFlow (Field Service mobile / offline forms).

Required metadata (every flow)

<processType>DataCaptureFlow</processType>
<areMetricsLoggedToDataCloud>false</areMetricsLoggedToDataCloud>
<environments>Offline</environments>
<!-- NO <apiVersion> tag -->

Optional IsLlmTargetable custom property — if you include it, it must be a JSON string, not a boolean:

<customProperties>
    <name>IsLlmTargetable</name>
    <value><stringValue>{&quot;value&quot;:&quot;false&quot;}</stringValue></value>
</customProperties>

The <booleanValue>false</booleanValue> form deploys but blocks activation — error: The value of the IsLlmTargetable custom property's value field must be a string in JSON format. Omitting the property entirely is also fine.

XML structure rules

Salesforce's Flow schema enforces grouping — all elements of the same type must appear in a single contiguous block. Deploy fails with Element X is duplicated at this location when violated.

Group order doesn't matter, but within each group elements must be adjacent:

• all <choices> together
• all <dynamicChoiceSets> together
• all <screens> together
• all <decisions> together
• all <recordLookups> together
• all <recordCreates> together
• all <recordUpdates> together
• all <loops> together
• all <assignments> together
• all <variables> together

Connector references determine execution order, not XML order.

Component reference

All extensions: prefix runtime_service_fieldservice:

Note: <fieldType>Range</fieldType> is NOT a valid slider fieldType in DataCaptureFlow (despite "Range/Slider" appearing in Builder UI lists). Sliders aren't available as pure metadata in this process type — use dcNumeric or dcCounter. forceContent:repeater (Lightning generic) ≠ <fieldType>Repeater</fieldType> (FSL offline). They share a concept, not XML.

Setting the label

All ComponentInstance extensions (including dcAddress and dcToggle) accept the label inputParameter — no wrapping DisplayText needed.

Required flag

Every input field needs <isRequired>true/false</isRequired> at field level. That single flag is sufficient for every dc* component — no extra required / isRequired inputParameter is needed.

dcLookup additionally accepts an isRequired inputParameter (boolean), but the field-level <isRequired> drives enforcement.

dcCheckbox and dcToggle accept <isRequired>true</isRequired> syntactically but don't enforce it at runtime.

Every input field must also have

<inputsOnNextNavToAssocScrn>UseStoredValues</inputsOnNextNavToAssocScrn>
<storeOutputAutomatically>true</storeOutputAutomatically>
<styleProperties>
    <verticalAlignment><stringValue>top</stringValue></verticalAlignment>
    <width><stringValue>12</stringValue></width>
</styleProperties>

Exception: <fieldType>Repeater</fieldType> explicitly rejects storeOutputAutomatically ("the storeOutputAutomatically field isn't supported"). Repeater output is always available as .AllItems — no opt-in needed.

Screen rules

Every screen needs ALL THREE of these or the Next/Finish button won't render:

• <allowFinish>true</allowFinish> (even on non-final screens)
• <showFooter>true</showFooter>
• <nextOrFinishButtonLabel>Next</nextOrFinishButtonLabel>

Plus:

• First element after <start> must always be a <screens> element
• All <screens> elements must be grouped together in the XML

Repeater — iterating rows and creating child records

The Repeater's output collection is exposed as .AllItems. Confirmed working on API v66.

<!-- On the screen: -->
<fields>
    <name>MyRepeater</name>
    <fieldType>Repeater</fieldType>
    <!-- NO storeOutputAutomatically on the Repeater itself -->
    <fields>
        <name>Row_PartName</name>
        <extensionName>runtime_service_fieldservice:dcTextInput</extensionName>
        <fieldType>ComponentInstance</fieldType>
        <storeOutputAutomatically>true</storeOutputAutomatically>
        <!-- … -->
    </fields>
    <fields>
        <name>Row_PartQty</name>
        <extensionName>runtime_service_fieldservice:dcCounter</extensionName>
        <fieldType>ComponentInstance</fieldType>
        <storeOutputAutomatically>true</storeOutputAutomatically>
        <!-- … -->
    </fields>
    <isRequired>false</isRequired>
</fields>

<!-- At end of flow: -->
<loops>
    <name>Loop_Parts</name>
    <collectionReference>MyRepeater.AllItems</collectionReference>   <!-- ← THE KEY -->
    <iterationOrder>Asc</iterationOrder>
    <nextValueConnector>
        <targetReference>Create_Part</targetReference>
    </nextValueConnector>
</loops>
<recordCreates>
    <name>Create_Part</name>
    <object>CustomFormPart__c</object>
    <connector>
        <targetReference>Loop_Parts</targetReference>   <!-- loops back -->
    </connector>
    <inputAssignments>
        <field>PartName__c</field>
        <value>
            <elementReference>Loop_Parts.Row_PartName.value</elementReference>
            <!-- ↑ LOOP name + nested field name + .value -->
        </value>
    </inputAssignments>
    <inputAssignments>
        <field>Quantity__c</field>
        <value>
            <elementReference>Loop_Parts.Row_PartQty.value</elementReference>
        </value>
    </inputAssignments>
    <storeOutputAutomatically>true</storeOutputAutomatically>
</recordCreates>

Don'ts:

• <collectionReference>MyRepeater</collectionReference> → Element "MyRepeater" doesn't exist
• <collectionReference>MyRepeater.items</collectionReference> → generic server error
• <collectionReference>MyRepeater.data</collectionReference> → generic server error
• Inside the loop body, MyRepeater.Row_PartName.value won't work — must use the loop's name, not the repeater's name.

Cross-row validation does NOT compile. Formula refs like r_GR4.AllItems[$Items].field.value and r_GR4.AllItems[$Items - 1].field.value fail with Syntax error. Per-row validation works via plain fieldName.value inside the nested field's own validationRule. For cross-row rules, use a post-screen loops + decisions.

Other Repeater accessors don't resolve today. Only .AllItems works. AddedItems, PrepopulatedItems, RemovedItems all fail deploy with doesn't exist.

Prepopulating a Repeater from an existing collection

Bind an existing SObject collection to the Repeater so it renders one pre-filled row per source record. The user can then edit, add, or remove rows before submit.

Pattern: recordLookups (get source collection, getFirstRecordOnly=false, storeOutputAutomatically=true) → screen with Repeater bound via the collection inputParameter → nested fields use SourceCollection[$EachItem].FieldApiName as their value default.

<recordLookups>
    <name>Get_Source</name>
    <object>ServiceResource</object>
    <getFirstRecordOnly>false</getFirstRecordOnly>
    <storeOutputAutomatically>true</storeOutputAutomatically>
    <connector><targetReference>Screen_Repeater</targetReference></connector>
    <!-- optional <limit>, <filters> … -->
</recordLookups>

<!-- On the screen: -->
<fields>
    <name>accountRepeater</name>
    <fieldType>Repeater</fieldType>
    <inputParameters>
        <name>collection</name>                                <!-- ← binds source rows -->
        <value><elementReference>Get_Source</elementReference></value>
    </inputParameters>
    <fields>
        <name>account_info</name>
        <fieldType>DisplayText</fieldType>
        <fieldText>&lt;p&gt;Id: {!Get_Source[$EachItem].Id}&lt;/p&gt;</fieldText>
        <!-- DisplayText inside the Repeater merges via SourceCollection[$EachItem].Field -->
    </fields>
    <fields>
        <name>name</name>
        <extensionName>runtime_service_fieldservice:dcTextInput</extensionName>
        <fieldType>ComponentInstance</fieldType>
        <inputParameters>
            <name>label</name>
            <value><stringValue>Name</stringValue></value>
        </inputParameters>
        <inputParameters>
            <name>value</name>
            <value><elementReference>Get_Source[$EachItem].Name</elementReference></value>
            <!-- ↑ prepopulates the editable field with the source record's value -->
        </inputParameters>
        <isRequired>true</isRequired>
        <storeOutputAutomatically>true</storeOutputAutomatically>
        <inputsOnNextNavToAssocScrn>UseStoredValues</inputsOnNextNavToAssocScrn>
        <styleProperties>…</styleProperties>
    </fields>
    <isRequired>false</isRequired>
    <styleProperties>…</styleProperties>
</fields>

Key points:

• The binding inputParameter is named collection, not value or source.
• Inside the Repeater, reference a source row via SourceCollectionName[$EachItem].FieldApiName — use the record-lookup's name, not the Repeater's name. Works in both DisplayText.fieldText (as {!Get_Source[$EachItem].Id}) and in component value defaults (as <elementReference>Get_Source[$EachItem].Name</elementReference>).
• $EachItem is the per-row iterator Salesforce injects while rendering the Repeater. It only resolves inside Repeater-nested fields.
• Downstream loops still iterate Repeater_Name.AllItems as normal — prepopulation changes the input, not the output accessor.
• Prepopulated rows appear as regular .AllItems entries after submit; there is no PrepopulatedItems / AddedItems split (those accessors fail deploy).

Displaying Repeater entries to the user (post-Repeater Loop screen)

To show the user what they captured (e.g. review / confirmation / per-row detail), put a Loop after the Repeater screen whose body connects to a display screen; the display screen then connects back to the Loop. The end connector of the Loop moves on to the next step.

<loops>
    <name>Loop_Through_Repeater</name>
    <collectionReference>accountRepeater.AllItems</collectionReference>
    <iterationOrder>Asc</iterationOrder>
    <nextValueConnector>
        <targetReference>Repeater_Output_Screen</targetReference>   <!-- body = display screen -->
    </nextValueConnector>
    <!-- <noMoreValuesConnector> → next step after the review is done -->
</loops>

<screens>
    <name>Repeater_Output_Screen</name>
    <connector><targetReference>Loop_Through_Repeater</targetReference></connector>   <!-- back to loop -->
    <fields>
        <name>display_info</name>
        <fieldType>DisplayText</fieldType>
        <fieldText>&lt;p&gt;Source Id: {!Loop_Through_Repeater.UniqueField__Id}&lt;/p&gt;
&lt;p&gt;Name: {!Loop_Through_Repeater.name.value}&lt;/p&gt;
&lt;p&gt;Type: {!Loop_Through_Repeater.description.value}&lt;/p&gt;</fieldText>
        <styleProperties>…</styleProperties>
    </fields>
    <allowFinish>true</allowFinish>
    <showFooter>true</showFooter>
    <nextOrFinishButtonLabel>Next</nextOrFinishButtonLabel>
</screens>

Accessor rules inside the loop body:

• User-captured values — {!LoopName.nestedFieldName.value} (same .value / .selectedChoiceValues / .isActive / etc. accessors as elsewhere).
• Source record Id for prepopulated rows — {!LoopName.UniqueField__Id}. This is a synthetic field the Repeater exposes on each iteration; it only carries a value for rows that came from the bound collection (new rows the user added will be blank).
• Use the loop's name, not the Repeater's name, inside the loop body — same rule as the canonical .AllItems + Create pattern above.

This loop-over-.AllItems display pattern composes with the Create/Update patterns: one loop for rendering a review screen, a later loop (or the same one, if ordering permits) for CUD. Remember the CUD rule — nothing (screens, gets, decisions) may sit between sequential CUD nodes, so any review loop must fully complete before the CUD chain starts.

CUD rules (hard platform constraints)

• A Decision can choose which CUD chain starts (e.g. Create vs Update branches of a save-mode decision). But once a CUD chain begins, no Decision may appear between sequential CUD nodes — deploy fails with Append multiple Create, Update, or Delete operations only at the end of the flow, in any order.
  • Workaround for "create only if filled" → always-create (accept blank rows), or move the conditional logic before the CUD chain begins.
• All CUDs at end of flow. No Get Records or screens after any CUD. No subflows containing CUD.
• Assignment-after-CUD inside a loop was bugged in v260. Fixed in v262 / API 66. Safe to use now.

Counter params

<inputParameters><name>min</name><value><numberValue>1.0</numberValue></value></inputParameters>
<inputParameters><name>max</name><value><numberValue>10.0</numberValue></value></inputParameters>
<inputParameters><name>step</name><value><numberValue>1.0</numberValue></value></inputParameters>
<inputParameters><name>minCustomErrorMessage</name><value><stringValue>…</stringValue></value></inputParameters>
<inputParameters><name>maxCustomErrorMessage</name><value><stringValue>…</stringValue></value></inputParameters>

Date params

<inputParameters><name>minDate</name><value><elementReference>$Flow.CurrentDate</elementReference></value></inputParameters>
<inputParameters><name>maxDate</name><value><dateValue>2027-12-31</dateValue></value></inputParameters>

Picklist compact mode

Only use isCompact=true when ALL labels ≤8 characters AND ≤5 options.

Lookup params

<inputParameters><name>objectApiName</name><value><stringValue>Asset</stringValue></value></inputParameters>
<inputParameters><name>searchedFields</name><value><stringValue>Name, SerialNumber</stringValue></value></inputParameters>
<inputParameters><name>isMultiSelection</name><value><booleanValue>true</booleanValue></value></inputParameters>
<inputParameters><name>recordIdCollection</name><value><elementReference>v_Ids</elementReference></value></inputParameters>

recordIdCollection — scoping the searchable set

• Builder label: Record IDs Collection. XML attribute: recordIdCollection (singular recordId + Collection suffix). recordIds fails deploy with We can't find this input attribute: "recordIds".
• It is a scoping filter, not a default pre-selection. Constrains the lookup to only search within the provided String collection of Ids.
• Only takes effect when isMultiSelection=true. In single-select mode it is silently ignored — the user sees the full unfiltered object.
• Canonical pattern: recordLookups (scoped subset) → loops + assignments (build String collection of Ids) → screen with dcLookup recordIdCollection=v_Ids. Works offline against Briefcase-primed data; target < 1s over ~60k records.
• Output in multi-select mode is {!Lookup.recordIds} (String collection); visibility rules and DML that previously used {!Lookup.recordId} (singular) must iterate the collection or take the first element.

dcLookup displayed label

dcLookup has no input parameter for the displayed field (no displayField/primaryField). The label in search results and the selected chip is driven by the object's Primary Compact Layout — first field in that layout wins. To change it: Setup → Object Manager → Object → Compact Layouts → reorder → assign as Primary (org-wide change). searchedFields controls matching, not display.

Flow-local alternative: swap dcLookup for dcPicklist backed by a dynamicChoiceSets with <displayField> / <valueField>.

Address with GPS

<inputParameters><name>useCoordinates</name><value><booleanValue>true</booleanValue></value></inputParameters>

Matrix

<inputParameters><name>questions</name><value><stringValue>["Q1","Q2","Q3"]</stringValue></value></inputParameters>

Escape & as & inside the JSON string.

2-column section

<fields>
    <name>MySection</name>
    <fieldText>Section Header</fieldText>
    <fieldType>RegionContainer</fieldType>
    <fields>
        <name>MySection_Col1</name>
        <fieldType>Region</fieldType>
        <fields><!-- components here --></fields>
        <inputParameters><name>width</name><value><stringValue>6</stringValue></value></inputParameters>
        <isRequired>false</isRequired>
    </fields>
    <fields>
        <name>MySection_Col2</name>
        <fieldType>Region</fieldType>
        <fields><!-- components here --></fields>
        <inputParameters><name>width</name><value><stringValue>6</stringValue></value></inputParameters>
        <isRequired>false</isRequired>
    </fields>
    <isRequired>false</isRequired>
    <regionContainerType>SectionWithHeader</regionContainerType>
    …styleProperties…
</fields>

Visibility rule

<visibilityRule>
    <conditionLogic>and</conditionLogic>
    <conditions>
        <leftValueReference>componentName.value</leftValueReference>
        <operator>GreaterThan</operator>
        <rightValue><numberValue>0.0</numberValue></rightValue>
    </conditions>
</visibilityRule>

Property accessors: .value (input components, including dcCheckbox), .selectedChoiceValues (choice components), .isActive (toggle), .firstName / .lastName (Name component), .recordId / .recordIds (Lookup single / multi).

The same accessors are also used inside recordCreates / recordUpdates inputAssignments — e.g. <elementReference>new_Reading.value</elementReference>.

Conditionally-hidden required fields — use validationRule, not isRequired

IF(TriggerField.selectedChoiceValues = "Yes",
   AND(NOT(ISBLANK(value)), value >= 0, value <= 100000),
   TRUE)

Canonical Decision IsNull pattern

IsNull takes a booleanValue on the right, NOT a null literal:

<conditions>
    <leftValueReference>v_ParentId</leftValueReference>
    <operator>IsNull</operator>
    <rightValue>
        <booleanValue>false</booleanValue>   <!-- true = is null, false = is not null -->
    </rightValue>
</conditions>

Calculation timing (CRITICAL)

Calculated values cannot display on the same screen that collects the inputs — calculations run only after the user taps Next. Pattern:

Screen N (collect inputs) → recordLookups / assignments / decisions → Screen N+1 (display results)

Screen N's connector must point to the calculation element, NOT to Screen N+1. All decision branches must eventually converge on Screen N+1.

DisplayText formula limitations (mobile runtime)

DisplayText in DataCaptureFlow has severely limited formula support compared to standard flows — complex formulas deploy fine and preview in Builder but fail at runtime with Error while resolving default value reference.

Fails at runtime:

• IF(Toggle.isActive, "YES", "NO") — any IF/CASE on component properties
• TEXT(CASE(...)), ADDMONTHS(...), nested date math
• Mixing multiple component refs + formulas in one fieldText

Works:

• Simple single variable: {!var_RiskScore}
• Simple component ref: {!MyPicklist.selectedChoiceValues}, {!MyNumeric.value}
• Global vars: {!$Flow.CurrentDate}, {!$User.FirstName}

Pattern: pre-calculate in an <assignments> element → store in a variable → reference that variable in DisplayText.

Global variables as input value defaults

Record Choice Set (dynamicChoiceSets) — mobile offline gotcha

<outputAssignments> inside a dynamicChoiceSets deploys fine but does NOT reliably populate the target variables at runtime in mobile offline DataCaptureFlow. Downstream screens render blank.

Correct pattern: keep the choice set minimal (displayField, valueField, filters, object, dataType). After the selection screen, route through a recordLookups filtered by Id = {!picklistName.selectedChoiceValues} and put extra fields into variables via the lookup's outputAssignments. Fits calculation-timing rule naturally (lookup sits between selection screen and display screen).

<recordLookups>
    <name>gr_SelectedChild</name>
    <filters>
        <field>Id</field>
        <operator>EqualTo</operator>
        <value><elementReference>pl_Child.selectedChoiceValues</elementReference></value>
    </filters>
    <getFirstRecordOnly>true</getFirstRecordOnly>
    <object>Child__c</object>
    <outputAssignments>
        <assignToReference>v_SelectedValue</assignToReference>
        <field>Reading_Value__c</field>
    </outputAssignments>
</recordLookups>

Visual polish patterns (verified render in mobile runtime)

Colors from the Lightning Design System: #2E844A (green), #0176D3 (blue), #FE9339 (orange), #C9C7C5 (neutral).

Hero banner

<div style="background: linear-gradient(135deg, #2E844A 0%, #0176D3 100%); color: white; padding: 20px; border-radius: 10px; text-align: center;">
  <p style="margin: 0; font-size: 22px;"><strong>🔧 Site Visit Report</strong></p>
  <p style="margin: 4px 0 0 0; font-size: 13px;">Subtitle</p>
</div>

Progress bar (per screen)

<p><b>Step X of N – 📍 Section Title</b></p>
<div style="width: 100%; height: 8px; background-color: #C9C7C5; border-radius: 4px; margin: 5px 0;">
  <div style="width: PERCENT%; height: 100%; background: linear-gradient(90deg, #2E844A 0%, #0176D3 100%); border-radius: 4px;"></div>
</div>

Separator between counter and title MUST be en dash – (U+2013), not hyphen.

Callout boxes

<!-- Info (blue) -->
<div style="background-color: #EAF5FE; border-left: 4px solid #0176D3; padding: 10px 14px; border-radius: 4px;">
  <p style="margin: 0; color: #014486; font-size: 13px;"><b>ℹ️ Info:</b> …</p>
</div>
<!-- Warning (orange) -->
<div style="background-color: #FFF4E6; border-left: 4px solid #FE9339; padding: 10px 14px; border-radius: 4px;">
  <p style="margin: 0; color: #704D00; font-size: 13px;"><b>⚠️ Heads up:</b> …</p>
</div>
<!-- Success (green) -->
<div style="background-color: #E8F5E9; border-left: 4px solid #2E844A; padding: 10px 14px; border-radius: 4px;">
  <p style="margin: 0; color: #1B5E20; font-size: 13px;"><b>✅ Ready:</b> …</p>
</div>

Review card (merge fields from prior screens)

<div style="border: 1px solid #DDDBDA; border-radius: 8px; padding: 14px 16px; background-color: #FAFAF9;">
  <p style="margin: 0 0 8px 0; color: #0176D3; font-size: 14px;"><b>📍 Section</b></p>
  <p style="margin: 2px 0;"><b>Name:</b> {!Input_SiteName.value}</p>
  <p style="margin: 2px 0;"><b>Contact:</b> {!Input_Contact.firstName} {!Input_Contact.lastName}</p>
  <p style="margin: 2px 0;"><b>Priority:</b> {!Input_Priority.selectedChoiceValues}</p>
  <p style="margin: 2px 0;"><b>After-hours:</b> {!Input_Toggle.isActive}</p>
</div>

All HTML must be XML-escaped in <fieldText>: & → &, " → ", < → <, > → >.

Deploying supporting objects alongside the flow

Custom object + field deploys do not auto-grant FLS/CRUD on the System Administrator profile. Flows running as the admin still can't read/write the new fields. Ship a PermissionSet and assign it:

<!-- MyObject_Access.permissionset-meta.xml -->
<PermissionSet xmlns="http://soap.sforce.com/2006/04/metadata">
    <label>My Object Access</label>
    <license>Salesforce</license>
    <hasActivationRequired>false</hasActivationRequired>
    <objectPermissions>
        <allowCreate>true</allowCreate><allowDelete>true</allowDelete>
        <allowEdit>true</allowEdit><allowRead>true</allowRead>
        <modifyAllRecords>true</modifyAllRecords><viewAllRecords>true</viewAllRecords>
        <object>MyObject__c</object>
    </objectPermissions>
    <fieldPermissions><field>MyObject__c.MyField__c</field><editable>true</editable><readable>true</readable></fieldPermissions>
    <tabSettings><tab>MyObject__c</tab><visibility>Visible</visibility></tabSettings>
</PermissionSet>

Assign after deploy: sf org assign permset --name MyObject_Access --target-org <alias>