Developer Field Deep Dive

Developer field deep dive

Overview

This skill is the developer persona's companion to v3.0's synthesis tier — the headline sfi.field_360 "show me EVERYTHING about this field" tool and the sibling sfi.field_lineage upstream/downstream walker — and the v2.0a Conditional Context foundation (firesWhen edges, ConditionalContext synthetic nodes) that v3.0 reads heavily.

The developer's first-line question is one of three shapes:

1. "Show me everything about Account.Industry__c." / "Field profile for Industry__c." — Use sfi.field_360, the v3.0 synthesis tool. Surfaces validates, formulas, writers, readers, UI, integrations, automations, emails, dependencies in one structured response.
2. "Where does this field's data come from?" / "What fires when this field changes?" / "Trace Industry__c upstream and downstream." — Use sfi.field_lineage with direction: 'upstream' | 'downstream' | 'both'. v2.7 cycle-detection + depth-bound discipline applies in both walks.
3. "What's Industry__c used in?" / "Who can see / edit Industry__c?" — Defer to developer-find-anywhere → sfi.find_field_anywhere for the simpler universal inventory, or to admin-sharing-troubleshooting for the per-user FLS cascade. The field-360 tool composes these inventories into one document; the simpler tools are right when the user wants ONE axis.

The boundary that matters for developers: sfi.field_360 surfaces dataNotAvailable: ['list-view-filters', 'reports', 'dashboards'] verbatim on EVERY response, regardless of whether the user's question explicitly named the unavailable categories. This is the Q165 honesty anchor — a synthesis tool that fails to disclose its omissions is a contract violation. v3.0 surfaces incoming references, readsFrom, writesTo, usedInLayout, firesWhen, and friends. What each dataNotAvailable entry now means is narrower than its name — read the anchor below before repeating it: list-view column and filter field identity IS composed (into the listViews section), and report/dashboard field usage IS folded onto the field as a property. What stays invisible is list-view filter PREDICATE EVALUATION, the literal value a report filters for, named credentials passing the field as a default argument, and managed-package callers.

The v2.0a synthetic ConditionalContext id-prefix classification brittleness: when field_360 surfaces the automations section (every Flow/WorkflowRule/ValidationRule/ApprovalProcess whose firesWhen edge references the target field), the rendering relies on the synthetic id prefix ConditionalContext:{ParentId}.condition-{N} to route the parent firer back to its rendering. A renaming of the parent (in particular, a CustomObject rename that cascades through the parentOf family) renames the synthetic id; the classification stability assumes the parent's canonical id is stable.

When to fire

Fire this skill on field-forensics / lineage / full-profile phrasing. Concrete triggers:

• "Show me everything about / give me the full profile for / field 360 on / deep dive on Account.Industry__c." — Use sfi.field_360.
• The same question about an OBJECT — "show me everything about Contact", "what is attached to this object", "what points at Invoice__c". — Use sfi.object_360 with objectApiName. Twelve sections: what the object CONTAINS and would take with it (owns), what lives outside and points AT it (usage), identity, brief, automations, permissions, relationships, recordTypes, sharing, recordPages, analytics, recordData. Two things to state when you render it:
  • It adjudicates nothing. summary.verdict is null by construction; there is no delete verdict and no blocker list. An object with active flows, profile grants or records is not thereby undeletable — those are consequences to weigh. Never translate its counts into "safe" or "unsafe to delete".
  • dataNotAvailable[] names what it refuses to fake — six RECORD-DATA gaps (field population, record recency, last record created/modified, record count, top owner / top creator, "when was this last used"), each naming the live tool that can answer it, plus report authorship, which is a permanent privacy boundary: the refresh never persists a report's author, owner or running user. The tool never calls the live plane itself.
• "Where does Industry__c's data come from?" / "What populates this field?" / "Trace the upstream lineage for Industry__c." — Use sfi.field_lineage with direction: 'upstream'.
• "What fires when Industry__c changes?" / "What automations depend on Industry__c?" / "Downstream lineage for Industry__c." — Use sfi.field_lineage with direction: 'downstream'.
• "Full lineage for Industry__c." / "Upstream + downstream trace." — Use sfi.field_lineage with direction: 'both'.
• "Document Account.Industry__c." — Use sfi.field_360 and surface the structured response.

When NOT to fire

Defer to another skill when:

• The user asks "what fields does Account have?" Schema lookup; defer to answering-org-questions → sfi.list_components / sfi.get_component.
• The user asks "do we have a field for customer health?" Natural-language field discovery; defer to developer-find-anywhere → sfi.find_semantic_field.
• The user asks "where is Industry__c used in Apex?" Apex- scoped reference question; defer to developer-apex-refactor → sfi.find_code_usages.
• The user asks "what breaks if I change Industry__c's type?" What-if projection; defer to developer-impact-and-reachability → sfi.what_if_change_field_type.
• The user asks "who can see Industry__c?" Sharing / visibility question; defer to admin-sharing-troubleshooting for the per-user cascade, or to developer-find-anywhere → sfi.field_access_audit for the per-grant inventory.
• The user asks for "what does Industry__c mean in our org?" Vocabulary question; defer to developer-find-anywhere → sfi.field_meaning for the per-field deep dive on the v2.9 classifications.
• The user asks "is this field dead?" Hygiene question; defer to developer-code-quality → sfi.find_dead_code with types: ['CustomField'].
• The user wants to MODIFY the field. v3.0 is read-only.
• The user asks about a FIELD on a non-CustomObject parent (e.g., a CustomMetadata field). The v3.0 tools accept CustomField: ids; for __mdt parents, sfi.explain_field surfaces record values. Pick the right granularity.

The cascade

Two synthesis tools — different shapes, complementary use cases.

1. sfi.field_360 — the synthesis tool

The v3.0 headline. Composes every prior tier's reads of a single CustomField into one structured response with per-section content cuts. Section composition table (per PLAN-v3.0 §4):

Default invocation (all sections):

{ "fieldId": "CustomField:Account.Industry__c" }

Subset narrowing:

{
  "fieldId": "CustomField:Account.Industry__c",
  "includeSections": ["writers", "automations"],
  "maxRowsPerSection": 50
}

The includeSections parameter narrows the response to a subset; the summary and boundaries[] / dataNotAvailable[] honesty surfaces are ALWAYS populated regardless of section filter, per the Q165 honesty anchor — synthesis-tier results without omission disclosure are a contract violation.

Per-section sorting is by source id ASC; truncation is bounded by maxRowsPerSection (default 50, hard cap 200). When a section truncates, the truncated flag flips true so the user can request a deeper walk.

When the response's confidence is reported as 'mixed', the sections span more than one edge-confidence level — the typical case for any real-org field. State per-section confidence in the response, not just the top-level mixed flag.

2. sfi.field_lineage — the provenance + effects walker

The sibling synthesis tool. Given a CustomField id and a direction ('upstream' | 'downstream' | 'both'), walks the writers (upstream) or effects (downstream) graph up to maxDepth hops (default 3, max 5).

Upstream walk — "where does this field's data come from?":

{ "fieldId": "CustomField:Account.Tier__c", "direction": "upstream", "maxDepth": 3 }

Starting from fieldId, queries incoming writesTo edges. Each writer is a source. Recurses into each writer for "where does THIS writer get its value FROM?":

• Flow INPUT fields (R6-11): a Flow writer's traced dataflow — the record fields its DML input assignments (or a R7-W2 before-save $Record.<Field> assignment) derive from — surfaces as flow-input-field sources one hop past the flow, and the walk recurses into each, so lineage chains end-to-end across multiple flows (A writes F1 from F2; B writes F2 from F3 → lineage of F1 reaches F3). Per-hop confidence: declared for direct $Record/record-lookup chains, heuristic through formulas/loops or a non-Assign assignment operator; inputs the extractor could not statically resolve are DISCLOSED in upstream.flowDataflow.unresolvedInputCount, never guessed. A Flow that writes a WHOLE record via a record-variable <inputReference> (R7-W1) is an OBJECT-level writer only — it shows up in object impact, not as a per-field writer (the fields are not enumerable; disclosed on the edge).
• Apex readsFrom edges.
• Formula upstream.
• WorkflowRule criteria items.
• Integration-inbound external system (terminal).
• v2.9 source-of-truth field (terminal — when the writer's properties.isSourceOfTruth is set).

Each source carries sourceKind: 'workflow-field-update' | 'flow-assignment' | 'apex-write' | 'process-builder-assignment' | 'formula-source' | 'flow-input-field' | 'integration-inbound' | 'source-of-truth-field'.

Downstream walk — "what fires when this field changes?":

{ "fieldId": "CustomField:Account.Tier__c", "direction": "downstream", "maxDepth": 3 }

Starting from fieldId, walks incoming firesWhen (v2.0a) + triggersOn + callsApex from automation surfaces reading the field. Each effect carries effectKind: 'flow-decision-branch' | 'apex-if-clause' | 'workflow-fire' | 'validation-fire' | 'integration-outbound' | 'email-fire' | 'formula-recompute' | 'flow-field-write'.

A flow-field-write effect (R6-11) is the downstream mirror of the flow dataflow: a Flow READS this field as a dataflow source and writes its value onward into the fields listed in its targetFields[]; the walk continues into each written field at depth + 1.

Each effect carries conditionId when the effect was sourced from a v2.0a ConditionalContext, and the verbatim firesWhen literal when the edge carries one.

Both walks:

{ "fieldId": "CustomField:Account.Tier__c", "direction": "both", "maxDepth": 3 }

Cycle detection: keyed by (fromId, toId, edgeType) tuples. Truncation rules inherit v2.7's discipline.

Fire sfi.run_analysis with { "name": "sfi.field_lineage", "args": { … } } when the user asks the trace question specifically (where does data come from, what fires on change) — the answer is the walk tree with per-step sourceKind / effectKind and firesWhen literal where applicable. Fire sfi.field_360 when the user asks for the broader profile.

Honesty axes

Q165 honesty anchor (verbatim — surface on EVERY field_360 / field_lineage response)

v3.0's synthesis layer reads what v0.1-v2.9 already extracted. The following categories are NOT extracted and surface as dataNotAvailable:

• List-view filters. The field IDENTITY of a list view's columns and filter predicates IS extracted and composed into the listViews section (heuristic regex; each row's referenceKind is fieldRef for a column, filterRef for a filter predicate, or columnAndFilter for both). What remains unmodeled — and what dataNotAvailable: 'list-view-filters' now names — is the saved view's runtime filter PREDICATE EVALUATION: whether a given record passes the filter. Never report the whole category as unextracted.
• Reports. The default refresh pulls a usage-ranked, capped slice of reports; sfi refresh --with-reports pulls all. Report field usage is folded onto the field (usedInReport, plus the capped usedInReports name list), so this category drops from dataNotAvailable and field_360 shows the in-use signal. Report NODES are also persisted, id Report:{LeafFolder}/{DeveloperName}. Their references edges go to the report's source object / custom report type only. There is deliberately NO report -> field edge: at real-org scale that layer was ~94% of the persisted rows for an answer the folded usedInReports property already gives, so field usage is a node PROPERTY and never an edge. Do not promise a graph walk from a field to its reports — read the folded property (first 50 names, with an exact truncation total), or open the Report: node those names identify. The report's own properties.fieldRefs lists the fields it uses. Filter/grouping LOGIC — operator, boolean AND/OR combination, and whether a literal value is set — is on the node. The literal value itself is NEVER persisted: a filter value is record data, which this product does not vault. "What value does this report filter for" is a permanent boundary, by design. Report/dashboard <description> text is likewise not persisted — only a descriptionPresent boolean. The per-report node set is CAPPED per type (SFI_REPORT_NODE_CAP, default 5000 — a blow-up guard set above observed real-org scale, not an operating point); when the cap bites, the Report/Dashboard coverage rows go pending, so absence claims about reports stay hedged. The FOLDED field usage is not capped by it — it covers every extracted report.
• Dashboards. Dashboard nodes are persisted the same way, with references edges to their component reports (Dashboard:{LeafFolder}/{Name} -> Report:{LeafFolder}/{Name}). A dashboard's <runningUser> is a real org username and is deliberately never read, so "who does this dashboard run as" is not answerable from the vault.
• Named-credential default-argument plumbing. A NamedCredential or ExternalService that passes this field as a default argument is captured only when the integration's payload schema declares the field.
• Managed-package callers. Managed-package source is not vaulted; classes inside a managed package may reference this field invisibly.

The dataNotAvailable[] array surfaces these categories verbatim on every response. Surface this; do NOT strip it.

v3.0 mixed-confidence rule

When the response's confidence is 'mixed', the sections span more than one edge-confidence level. State per-section confidence in the response. Example: the validates section is declared (metadata XML), the formulas section is parsed (formula tokenizer), and the readers section is mixed — Apex reads are parsed when the default-on Apex AST resolved the receiver (dropping to heuristic only on the recall scanner's parse-failure backfill), Flow record-lookups are parsed, and LWC/Aura/VF frontend reads stay heuristic.

v2.0a synthetic-id classification brittleness

The automations section in field_360 and the downstream walk in field_lineage surface firesWhen edges targeting v2.0a ConditionalContext synthetic nodes. The synthetic id format is ConditionalContext:{ParentComponentId}.condition-{index} where {ParentComponentId} is the firer's full canonical id and condition-{index} is the zero-indexed source-order position.

The stability rule: renaming a firer renames the source side of every firesWhen edge it owns; the synthetic ConditionalContext id changes accordingly. Reordering conditions within a firer (e.g., moving a <decisions> block in a Flow's canvas) renames the affected ConditionalContext nodes — which is correct behavior (a different position binding IS a different synthetic entity) but a brittleness to communicate when the developer is deciding to refactor the parent firer.

When the response surfaces a ConditionalContext synthetic id, state the parent firer it belongs to verbatim. Don't paraphrase the synthetic id; render it as-written.

v2.7 inheritance — cycle and depth discipline

sfi.field_lineage inherits v2.7's cycle detection (keyed by (fromId, toId, edgeType) tuples) and depth bound (default 3, max 5). When the walk truncates at maxDepth, surface the truncatedAtDepth flag and offer the user the option to widen. When the walk detects a cycle, surface the cycle's start / end / length (e.g., a self-enqueueing Queueable that writes the field).

v3.0 field_360 cap discipline

Per-section truncation is maxRowsPerSection (default 50, hard cap 200). When a section truncates, the truncated flag flips true. State the truncation explicitly in the response so the developer knows the section is incomplete.

dataNotAvailable is per-response, not per-section

The dataNotAvailable[] array surfaces on every response, regardless of which sections are included. Even when the user's question explicitly asks for only one section, the array surfaces the full omission list. This is constitutional — omission disclosure is independent of section filter.

Worked example

User: "Show me everything about Account.Industry__c."

Claude's flow:

1. Classify → full profile, use sfi.field_360.
2. Fire sfi.run_analysis with { "name": "sfi.field_360", "args": { … } } with { "fieldId": "CustomField:Account.Industry__c" }.
3. Receive (illustrative):

{
  "data": {
    "fieldId": "CustomField:Account.Industry__c",
    "fieldShape": {
      "apiName": "Industry__c",
      "label": "Industry",
      "type": "Picklist",
      "required": false,
      "description": "Industry segment for the account. Populated by SalesforceConnect nightly OR by Account Owner manually."
    },
    "sections": {
      "validates": [
        { "id": "ValidationRule:Account.Require_Industry", "type": "ValidationRule", "edgeConfidence": "declared", "explanation": "Requires Industry__c to be set on save when RecordType = Enterprise" }
      ],
      "formulas": [
        { "id": "CustomField:Account.Tier_Display__c", "type": "CustomField", "edgeConfidence": "parsed", "explanation": "Formula field references Industry__c via TEXT(Industry__c)" }
      ],
      "writers": [
        { "id": "ApexClass:IndustryUpdater", "type": "ApexClass", "edgeConfidence": "parsed", "source": "apex-ast", "explanation": "Apex AST resolved `acc` to Account and parsed a write to Industry__c on line 47" },
        { "id": "Flow:Sync_Account_From_External", "type": "Flow", "edgeConfidence": "parsed", "explanation": "Flow recordUpdate element 'update_industry' writes Industry__c" },
        { "id": "ExternalDataSource:SalesforceConnect_Industries", "type": "ExternalDataSource", "edgeConfidence": "declared", "explanation": "Integration writes via Salesforce Connect nightly sync" }
      ],
      "readers": [
        { "id": "ApexClass:AccountReportBuilder", "type": "ApexClass", "edgeConfidence": "heuristic", "source": "apex-scanner", "explanation": "recall scanner saw acc.Industry__c read on line 215 — this file fell back to the scanner (AST parse failure), so confidence is heuristic" },
        { "id": "Flow:Tier_Account_By_Industry", "type": "Flow", "edgeConfidence": "parsed", "explanation": "Flow Get Records element reads Industry__c into the loop" },
        { "id": "LightningComponentBundle:industryDashboard", "type": "LightningComponentBundle", "edgeConfidence": "heuristic", "explanation": "LWC wire imports @salesforce/schema/Account.Industry" }
      ],
      "ui": [
        { "id": "Layout:Account.Standard_Layout", "type": "Layout", "edgeConfidence": "declared", "explanation": "Field placed in Account Information section" }
      ],
      "integrations": [
        { "id": "ExternalDataSource:SalesforceConnect_Industries", "type": "ExternalDataSource", "edgeConfidence": "declared", "explanation": "OData4 endpoint, nightly sync" }
      ],
      "automations": [
        { "id": "Flow:Notify_Industry_Change", "type": "Flow", "edgeConfidence": "declared", "conditionId": "ConditionalContext:Flow:Notify_Industry_Change.condition-0", "firesWhen": "Industry__c != PRIORVALUE(Industry__c)", "explanation": "Flow decision branch fires on Industry__c change" }
      ],
      "emails": [],
      "dependencies": []
    },
    "summary": { "totalReferrers": 9, "sectionCounts": { "validates": 1, "formulas": 1, "writers": 3, "readers": 3, "ui": 1, "integrations": 1, "automations": 1, "emails": 0, "dependencies": 0 } },
    "confidence": "mixed",
    "dataNotAvailable": ["list-view-filters", "reports", "dashboards"],
    "boundaries": [
      "v3.0 synthesis reads what v0.1-v2.9 already extracted. List-view filter EVALUATION, report/dashboard filter literals, named-credential default-argument plumbing, and managed-package callers are NOT extracted; this field may have references in those categories that are invisible to this report.",
      "Section confidence is mixed — see per-section labels. Parsed Apex edges (source apex-ast) are high-confidence; the remaining heuristic edges (Apex recall-scanner backfill on parse-failure files, LWC scanner field reads) need source verification before refactoring."
    ]
  }
}

4. Respond:

Full profile for CustomField:Account.Industry__c:

Shape

• Label: Industry
• Type: Picklist
• Required: No
• Description: "Industry segment for the account. Populated by SalesforceConnect nightly OR by Account Owner manually."

Validates (1, declared)

• ValidationRule:Account.Require_Industry — requires Industry__c on save when RecordType = Enterprise.

Formulas (1, parsed)

• CustomField:Account.Tier_Display__c — formula field references Industry__c via TEXT(Industry__c).

Writers (3, mixed)

• ApexClass:IndustryUpdater (parsed, apex-ast) — the Apex AST resolved acc to Account and parsed a write to Industry__c on line 47. High-confidence.
• Flow:Sync_Account_From_External (parsed) — Flow recordUpdate element update_industry writes Industry__c.
• ExternalDataSource:SalesforceConnect_Industries (declared) — integration writes via Salesforce Connect nightly sync. This is the primary writer.

Readers (3, mixed)

• ApexClass:AccountReportBuilder (heuristic, apex-scanner) — this file fell back to the recall scanner (AST parse failure), which saw acc.Industry__c read on line 215. Verify before relying on it.
• Flow:Tier_Account_By_Industry (parsed) — Flow Get Records element reads Industry__c into the loop.
• LightningComponentBundle:industryDashboard (heuristic) — LWC @wire imports @salesforce/schema/Account.Industry.

UI (1, declared)

• Layout:Account.Standard_Layout — field placed in Account Information section.

Integrations (1, declared)

• ExternalDataSource:SalesforceConnect_Industries — OData4 endpoint, nightly sync. Schema declares Industry__c explicitly.

Automations (1, mixed)

• Flow:Notify_Industry_Change (declared, ConditionalContext:Flow:Notify_Industry_Change.condition-0) — flow decision branch fires when Industry__c != PRIORVALUE(Industry__c) (the v2.0a conditional context expression). When you change a writer or the field type, this Flow's branch behavior may change.

Emails: 0 referrers. Dependencies: 0 outgoing references (this is a Picklist, not a formula field).

Total referrers: 9 across 6 sections. Section confidence is mixed — Apex / LWC scanner reads are heuristic, Flow + formula references are parsed, validation + integration declarations are declared.

Important omissions (Q165 verbatim disclosure):

Three categories surface in dataNotAvailable — list-view-filters always, plus reports / dashboards when that family was not retrieved. Two more are named in boundaries[] rather than in the array; both are listed here:

• List-view filters. The listViews section names the list views whose columns or filter predicates reference Industry__c. What is NOT modeled is whether a given record passes such a filter.
• Reports. Report field usage is folded onto the field (usedInReport plus the capped usedInReports name list) and Report: nodes persist, but the literal value a report filters FOR is never persisted.
• Dashboards. Same shape: usedInDashboard is folded and Dashboard: nodes persist; component-level filter literals are not.
• Named-credential default-argument plumbing. A NamedCredential that passes Industry__c as a default argument is captured only when the integration's payload schema declares the field.
• Managed-package callers. Any managed-package code referencing this field is invisible.

Before treating this profile as exhaustive, sanity-check the list-view / report dimension manually (Setup → Object Manager → Account → List Views; and your reports folder).

For the upstream + downstream lineage walk (where the data comes FROM and what fires when it changes), run sfi.field_lineage with { direction: 'both', fieldId: 'CustomField:Account.Industry__c' }.

The response leads with shape, surfaces each section with its per-section confidence label, names the v2.0a ConditionalContext synthetic id verbatim, and APPENDS the Q165 disclosure — the three-item dataNotAvailable array plus the two boundaries[] omissions — spelled out.

Anti-patterns

See also

• developer-find-anywhere — for the SIMPLER per-field universal inventory (sfi.find_field_anywhere) when the user just wants "where is this used" without the full v3.0 synthesis. The v3.0 field_360 is the heavier composition; the v2.2 universal search is the lighter inventory.
• developer-impact-and-reachability — for what-if projection ("what breaks if I change Industry__c's type") and call-graph walks. v3.0 surfaces the current state; v2.3 projects the changed state.
• developer-code-quality — for hygiene scans (sfi.find_dead_code with types: ['CustomField']) once the full profile is in hand.
• architect-impact-analysis — for cross-component impact via sfi.get_impact. Field-360 surfaces incoming references; the architect's sfi.get_impact walks them transitively for the deprecation question.
• admin-sharing-troubleshooting — for per-user FLS cascades on the field. Field-360's ui section surfaces layouts; the admin skill answers "why can't user X edit this field".

Grounding & routing (shared contract). For a vague or broad ask, call sfi.route_question first — in the default hybrid mode it returns a meaning-ranked toolCandidates shortlist (which YOU pick from) plus a suggested plane and a route hint (and whether to sfi.resolve a name first). Default tool profile is core: only the core spine (including sfi.live_consent) is directly invokable. For every other sfi.* analysis, call sfi.run_analysis with { "name": "sfi.<tool>", "args": { … } } (or follow route_question.invoke, which already wraps non-core steps). Optional: sfi.describe_analysis first when args are unclear. Every org fact must come from an sfi.* tool call, cited by its canonical id — never from memory. Build the answer only from what the tools returned, then pass it through sfi.synthesize_answer, which flags any hallucinatedIds (canonical ids no tool produced). Full cascade: using-sf-intelligence.