Filament Table Field Laravel Package

Product Decisions This Supports

• Build vs. buy for inline relationship CRUD. The recurring "manage child records without leaving the parent form" requirement normally costs 3–6 dev-days of custom Blade/Livewire work per entity. This package collapses that to a composer require plus schema configuration, so the decision shifts from "can we afford to build it?" to "does the UX fit?"
• Form architecture and UX scope. Supports HasMany and BelongsToMany with create/edit/delete in modals, synced to the parent on save. This enables single-screen workflows (one save button, one validation surface) instead of forcing users into separate resource pages — a concrete reduction in clicks-per-task that can be cited in UX/flow reviews.
• Where this fits in the roadmap. Best value for admin panels, internal tools, and wizard/modal flows where a full Filament Resource RelationManager is too heavy or unavailable (e.g., front-end forms, custom actions, multi-step wizards). Treat it as a form-level capability, not a replacement for resource-level relation management.
• Data-integrity and business-logic placement. beforeCreateRecord() / beforeUpdateRecord() with auto-merged return values and injected parent form state/model context let you push derived defaults (tenant ID, ownership, computed fields, status) into the child record without forking the field. That is a real reduction in duplicated logic — but it also means business rules will live in form hooks, which is a maintainability decision worth flagging to engineering leadership.
• Feature-flag style rollout. Per-field toggles for create/edit/delete plus custom heading/empty-state text make this shippable behind a permission or role check without code branches, so it can be piloted with one team before broad release.
• Roadmap inputs from the vendor's "Coming Soon" list. Missing beforeDeleteRecord() and afterCreateRecord()/event emit are the gaps most likely to block audit logging, cascading cleanup, and notification workflows. Drag-and-drop reordering blocks any ordered-collection use case. Plan these as your dependencies, not assumptions.

When to Consider This Package

Adopt when most of the following hold:

• You are on Filament and need child-record CRUD embedded inside a form (modal, wizard step, custom action) rather than on a dedicated Resource page.
• Your relationships are plain HasMany / BelongsToMany and you can express the child schema declaratively (no bespoke multi-column layouts or heavy conditional logic per row).
• Your create/update logic fits cleanly into the two existing hooks — you don't need post-save events, delete-time side effects, or ordering.
• The feature is internal-facing or otherwise tolerant of a young dependency, and you can pin the version explicitly in composer.json.
• You're willing to write the acceptance tests yourself; v1.0.0 ships with no unit test coverage (listed as coming soon).

Look elsewhere or defer when:

• You need policy/authorization enforcement per row. Authorization behavior is not stated in the release notes — verify it against Filament policies before committing, especially for multi-tenant or customer-facing surfaces.
• Delete-time logic matters (soft deletes, cascade rules, audit trails) — beforeDeleteRecord() doesn't exist yet.
• Ordering matters — no drag-and-drop; use a Repeater with orderColumn or a custom implementation instead.
• You need transaction semantics guarantees across parent + children on save; confirm behavior rather than assuming atomicity, and load-test bulk edits.
• Your team is not on the matching Filament major version. The package is tightly coupled to Filament Tables internals; a Filament upgrade becomes a coordinated upgrade. Weigh this against native RelationManager, which moves with the framework.
• You need first-class vendor support or an SLA. A single-maintainer v1.0.0 with an unshipped plugin-integration path is a pilot-grade dependency, not a platform bet.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost add-on that removes a repeated build task — editing related records without leaving a page. Instead of paying for custom CRUD screens for every parent-child relationship, we configure a field. Expect days, not weeks, of effort for the first use case, and a reusable pattern for the next several. The trade-off is maturity: it's a brand-new 1.0 release from a single maintainer with no automated tests yet, so we're recommending a scoped pilot in an internal admin area with the version pinned, and a re-evaluation before we depend on it anywhere customer-facing.

For engineering: It's a Filament form field backed by Filament Tables that handles HasMany/BelongsToMany child records through modals and syncs them on parent save. Configuration covers per-field enable/disable of create/edit/delete, custom heading and empty states, default record values, and dynamic schema/columns. Two lifecycle hooks — beforeCreateRecord() and beforeUpdateRecord() — receive parent form state and model context, and their return values merge into the modal form data, which is where we'd put tenant scoping and derived defaults. Known gaps: no beforeDeleteRecord(), no post-create event, no reordering, no test suite, and no official plugin packaging yet — so anything requiring delete-time side effects or ordered collections needs custom work today. Concrete asks before we merge: pin the version, confirm authorization against Filament policies, add feature tests around the save/sync path, and confirm transaction behavior on multi-record edits.