Field Customizers will be retired in 2026 - Lack of alternative ?

[stevebeauge]

Hi,

I recently discovered that SPFX Field customizer will retired next year (Support update for SharePoint framework field customizers in lists and document libraries ). We'll must use custom JSON formatting.

AFAIK, the only possible "interactivity" we can add to fields with JSON, is formatting hyperlink, and using customRowAction, which is very limited. JSON Formatting is good for making a cell green or red based on a value, but not really more.

We'll loose ability to:

• format data based on custom business rules computation
• load additional data, not present in current view
• have custom behavior inside the column
• ...

Can you clarify if I'm missing something ?

Concrete example of one of our main use case:

• in a library, we have a button that is visible only if some conditions are met (based on a JSON complex structure stored in the field)
• when the use click the button, a dialog opens, letting him choose some options with business logic (cascading options, technical checks, ...)
• A OK button that write the options in a field to let a custom web hook starts a workflow.

This use case will simply be impossible to implement at scale without field customizer. Power Apps and Power Automate are impossible to deploy in multiple site collections.

Thanks

[andrewconnell]

This is a horribly STUPID decision by Microsoft, breaking yet another promise for the development & customization of SPO.

The suggested alternatives don't address existing scenarios, introducing a clear feature gap.

This is yet another half-assed feature that was never finished, adding support beyond a read-only experience, which Microsoft committed to when they were released in 2017.

👎👎

[Adam-it]

I just noticed this today as well in my inbox, and this decision makes me just sad 😕.
It's another use case where us (developers) get cut on functionality and possibilities and are 'forced' to switch to low-code and no-code approach.
I totally agree that list formatting is extremely awesome and provides many possibilities, but suggesting this as an alternative to Field customizer just feels like a bad joke 😁. List formatting provides amazing opportunities for a user to make their lists pretty and somehow enhanced, but it lacks the possibility for enterprise-level customization like:

• We may not run any custom logic under the hood
• Yes you may customize the UI with it but it is somehow limited, especially if we compare it to what we could do in code where sky is (sorry soon was) the limit
• Provisioning is 'hacky'. Yes, we may create scripts using either CLI for Microsoft 365 or PnP PowerShell to apply list formatting for many lists on a site or in our tenant but with SPFx the provisioning story was natural and similar to other SPFx components, not a hacky script
• List formatting (at least in the projects in which I worked) where never like part of the solution. We never had a place to keep this JSON somewhere as part of our project/product we built and then apply to a site, as list formatting was always considered something that empowers users, not something a developer should use as a standard component of their bigger solution. Field Customizers were for that, just another SPFx component that was part of our bigger solution we develop and provide to the customer.

Could we get a bit more insight as to why this decision was made🙏?
Is it because Field Customizers are just not used other than in developer tenants? Or will a Field Customizer added to a list make it hard for Copilot to reason over such data, or is it just not possible to support it, so it's better to get rid of it then 🤷‍♂️ (only joking here, I really hope this would not be the reason 😜)

[jblueml]

This statement leads me to believe that Microsoft is underestimating the impact of this change due to the lack of alternatives.

[andrewconnell]

... that's one possibility

Another possibility: they don't care.

Why else would they (1) bury the news in a new post to the message center on a Friday (Friday 13th none the less) AND (2) not comment on the WHY in the 4+ days since it was announced.

[lafe]

I am constantly saying that JSLink was peak SharePoint development. It was an immensely powerful and awesome way to customize forms, fields and views and it allowed to just replace certain aspects instead of rebuilding everything. In my experience, SPFx is good to build Webparts, but everything related to customizing SharePoint OOTB features is worse than before and SPFx has yet to reach feature parity with JSLink (and based on this announcement, it never will...). Instead they go on side quests (e.g. integration in Teams, Viva Connections, etc.) instead of focussing on the core functionality before extending the scope. And don't get me started on the extremely old libraries (e.g. React 17) that we still have to work with... (and the announced update is not to React 19 but React 18...).

My wish would be to make SharePoint Framework Field Customizers more powerful to reach feature parity with JSLink and invest in the framework, instead of deprecating parts of it that may cause issues in some aspects.

[stevebeauge]

I sometime feel like MS shifted from a platform which embraces strong dev ecosystem, to a platform where selling copilot is the only objective :(