Flex Fields Laravel Package

Product Decisions This Supports

• Ship "custom fields without engineering" as a product capability. This package turns schema changes into admin-configurable work. That unlocks self-serve field management for internal tools, customer-configurable record types, and per-tenant data models — anything where the field list is a support ticket today and a config screen tomorrow.
• Build vs. buy for form/record infrastructure. Repeaters, conditional visibility, validation builders, translatable fields, field groups, CSV import preview, and record history are all table-stakes in a serious internal tool and all individually expensive to build. Adopting this converts months of platform work into a dependency and lets the team spend that budget on domain logic instead.
• Unblocks the API/import/AI ingestion roadmap. 0.6.1 specifically fixes repeater items created programmatically (API, imports, AI tools) not rendering in the admin form. That means machine-written records and human-edited records now share one representation. Any roadmap item that writes structured data into dynamic fields — bulk import, integrations, LLM-assisted data entry — becomes demoable rather than fragile.
• Makes "show in table" a product-level toggle, not a developer task. Fields flagged is_shown_in_list now render as real columns (including boolean, image, color, formatted text) and are searchable when the field is searchable. That is the difference between a list view that reflects the customer's schema and one that requires a migration per column request.
• Sets expectations for release cadence and versioning. 0.6.1 is a patch on a pre-1.0 package, and its headline fixes are correctness bugs in data round-tripping plus a docs refresh. Plan for frequent minor upgrades and read changelogs before bumping.

When to Consider This Package

Adopt when most of the following hold:

• You are on Laravel + Filament and the admin panel is a real product surface, not an afterthought.
• The field set for a record type varies by tenant, team, or customer, or changes often enough that migrations are a bottleneck.
• You need repeatable/structured sub-fields (line items, contacts, addresses) and want them editable in the UI and writable from an API or importer.
• You want conditional visibility, validation rules, translations, and record history without assembling four separate plugins.
• You need a CSV import preview path that lands in the same field definitions the form uses.
• You can accept a 0.x dependency with a fast-moving API, and you have someone who will read release notes.

Look elsewhere when:

• You are not on Filament — most of the value here is in the admin form and table integration.
• Your schema is genuinely fixed. Dynamic fields add indirection and query complexity you will pay for with no benefit.
• You need long-term API stability guarantees or a vendor SLA. Pre-1.0, no prior assessment exists, and this release alone changed how stored repeater keys are normalized on read — that is the kind of change you want to test against production-shaped data.
• You require heavy reporting/analytics on dynamic fields. Column-per-field rendering in a table view is not the same as a warehouse-grade query layer.
• Your compliance posture requires audited, versioned schema changes rather than runtime configuration.

Two specific things to verify before committing: how the legacy ff_-prefixed key normalization behaves on write (this release normalizes on read only — confirm your existing rows are migrated or that read-normalization is enough), and whether searchable dynamic columns perform acceptably at your row counts.

How to Pitch It (Stakeholders)

For executives: This is infrastructure that lets us stop rebuilding the same admin screens. Customers and internal teams get configurable fields, lists, validation, and history without engineering cycles, and the data those screens produce is now the same data our API, imports, and AI tooling write. One shared model, fewer bespoke migrations, faster time-to-market on anything that looks like a record-keeping product. It is a pre-1.0 open-source dependency, so the trade is speed now for upgrade discipline later — a reasonable trade at this scope.

For engineering: A Filament-native dynamic fields package. Version 0.6.1 fixes the round-trip between programmatically-created records and the admin form: repeater sub-fields now use declared sub-field keys rather than ff_-prefixed ones, and legacy prefixed rows are normalized on read. It also wires is_shown_in_list through to actual table columns — boolean, image, color, formatted text — with searchability inherited from the field's searchable flag, and exposes the toggle in the custom field form. Docs and screenshots refreshed. No breaking changes called out, but the read-path normalization means you should run it against a copy of real data before rolling out, and confirm nothing writes ff_-prefixed keys going forward.