Form formatting: a library header resolves almost no tokens (file identity blank, lookup returns raw id;#value, .lookupValue blank, custom date renders Invalid Date)

Summary

In a document library's form formatting header (headerJSONFormatter on the list's content type ClientFormCustomFormatter), most field tokens do not resolve, and two of them fail in ways that are worse than rendering blank.

Measured on SharePoint Online, 2026-09-13, on a library created for the purpose. Every line below came from one header on one display form, so the working and non-working cases were rendered by the same expression shape at the same moment.

What works

Token	Rendered
[$ID]	1
[$Modified]	13/09/2026 11:40 PM
[$Title]	the typed value, once the column has one
[$MyChoice] (Choice)	Q3
[$MyNumber] (Number)	2026

What does not

1. No spelling of a file's identity resolves

All fourteen render empty:

FileLeafRef, FileRef, Name, LinkFilename, LinkFilenameNoMenu,
FileDirRef, File_x0020_Name, DocIcon, EncodedAbsUrl, ServerUrl,
File_x0020_Type.

So there is no way to put a file's own name in its form header. This part reproduces #7964 (opened 2022-05-17, closed as type:archive-old-issue with no fix). That issue named two of the fourteen and never established which tokens do work, which is what the table above adds.

2. A custom Date column renders Invalid Date, and takes the whole line with it

For a custom SP.FieldDateTime column holding a value:

"txtContent": "='MyDate -> [' + [$MyDate] + ']'"

renders, in full:

Invalid Date

The label, the arrow and the brackets are all gone. This is worse than a blank, because a blank leaves the rest of the header standing and this destroys the entire expression.

The contrast is the interesting part: [$Modified] in the same header, same concatenation shape rendered 13/09/2026 11:40 PM correctly. A built-in date field works where a custom date column does not.

3. A Lookup resolves to the raw stored form

MyLookup -> [1;#Privacy and health records]

That is the internal <id>;#<value> encoding, not a display value.

4. [$MyLookup.lookupValue] renders empty

MyLookup.lookupValue -> []

.lookupValue is the documented accessor for exactly this case in column and view formatting. In a form header it returns nothing, which leaves no documented way to show a lookup's display value in a header.

Repro

Minimal case. Create a document library with a Choice, a Number, a DateTime and a Lookup column, give one file a value in each, then store this as a string in ClientFormCustomFormatter on the library's Document content type:

{
  "headerJSONFormatter": {
    "elmType": "div",
    "style": { "display": "flex", "flex-direction": "column" },
    "children": [
      { "elmType": "div", "txtContent": "='FileLeafRef -> [' + [$FileLeafRef] + ']'" },
      { "elmType": "div", "txtContent": "='Modified -> [' + [$Modified] + ']'" },
      { "elmType": "div", "txtContent": "='MyChoice -> [' + [$MyChoice] + ']'" },
      { "elmType": "div", "txtContent": "='MyNumber -> [' + [$MyNumber] + ']'" },
      { "elmType": "div", "txtContent": "='MyDate -> [' + [$MyDate] + ']'" },
      { "elmType": "div", "txtContent": "='MyLookup -> [' + [$MyLookup] + ']'" },
      { "elmType": "div", "txtContent": "='MyLookup.lookupValue -> [' + [$MyLookup.lookupValue] + ']'" }
    ]
  }
}

Open the file's details panel and read the header.

A scripted version that builds the library, the columns, the lookup target and the header, and prints the results, is here. Paste it into the browser console on a site you own; it refuses to write anything until two flags are set, and it cleans up after itself:

https://github.com/firmfooting/dbml-sharepoint/blob/4af91908/test/manual/library-header-token-probe.js

Expected

• A field token that resolves in a column or view formatter resolves in a header, or the documentation says which subset a header supports.
• A Lookup yields its display value, and .lookupValue works as documented.
• A custom Date column renders its value, as Modified already does, rather than replacing the surrounding expression with Invalid Date.

Documentation gap

"Use form formatting to customize SharePoint" documents the header, body and footer sections and the JSON shape, but does not say which tokens a header can resolve. Everything above had to be measured. If the restriction is by design, listing the supported tokens on that page would be enough.

Related

• #7964, same header, two of the same tokens, closed unfixed.

Still being measured

Whether any of these has a working route we have not found yet: whether a header evaluates substring and indexOf at all (which would allow trimming <id>;# off a lookup), whether a read-only projected lookup column renders its value cleanly, and whether any spelling gets a custom date to render (.displayValue, toLocaleDateString, toLocaleString, toDateString, or the bare token with nothing concatenated to it). The probe linked above carries that battery. I will comment here with the results either way, since a working workaround would change what is worth fixing.