Formsettings For Filament Laravel Package

Product Decisions This Supports

• Per-user form ergonomics without a form-builder rewrite. The package layers onto existing Laravel form pages via a HasFormSettings trait or a global opt-in, so product can ship personalization (hide optional fields, reorder tab flow, set an autofocus entry point, choose default submit action) without touching validation, persistence, or controller logic.
• Reduced time-to-value for power users. Field reordering and hide/show directly address repetitive data-entry workflows (ops, finance, back-office CRUD); the submit-action picker (save / save & next / save & back) supports high-volume "create another" loops that are common in admin tooling.
• Build vs. buy signal. This is a narrowly scoped UX-preference layer, not a form builder or workflow engine. Buying/ adopting it is justified when the roadmap item is "let users customize their forms" and not "let users define new forms." It removes an estimated custom UI + persistence + translation + reset/preset surface from the backlog.
• Roadmap input. Named presets and one-click reset make it viable for multi-persona or multi-team deployments (e.g., a "support triage" preset vs. a "data entry" preset), which can inform whether preferences become a first-class, shareable/team-level concept later.
• Use cases: internal admin panels, back-office data entry, CRM/ERP-style create forms, any Laravel app with long forms where field order and optional-field noise are recurring complaints. Poor fit for customer-facing marketing forms where users should see a fixed, designed experience.

When to Consider This Package

Consider adoption when:

• The form pages are internal/authenticated and users are tolerant of (or actively want) per-user layout preferences.
• Your forms are Laravel-rendered and you can attach a trait to the relevant form pages or enable it globally with low blast radius.
• You need per-user persistence across devices — this requires opting into ->persist() and shipping the associated migration/config publish, so plan for that in the estimate.
• You want a fast, low-risk pilot: session storage by default means you can trial the UX with zero schema changes and promote to DB persistence once validated.
• You need German and English only, or can contribute translations.
• You are comfortable pinning a v0.1.x dependency: pre-1.0 means no stability guarantee, and the trait/API surface (->globally(), ->persist(), ->presets()) may shift.

Look elsewhere or defer when:

• You need team/role-level or org-wide shared presets — this release is per-user only.
• You need form definition/builder capabilities, conditional logic engines, or server-side validation changes; this package deliberately does not do that.
• You require multi-tenant isolation guarantees or a documented authorization model for settings; v0.1.0 does not advertise one, so treat that as an engineering review item.
• Your UI is Inertia/React/Vue SPA-driven or non-Laravel Blade; the package is form-page/trait oriented and may not fit without glue work.
• You need localization beyond DE/EN, accessibility conformance evidence, or automated test coverage as an adoption gate — the release notes cite browser QA, not a published test suite.
• Your compliance posture requires a 1.0+/LTS dependency with a deprecation policy.

How to Pitch It (Stakeholders)

For executives: This is a small, self-contained package that lets each user tailor long forms to the way they actually work — hide fields they never fill, reorder the flow, pick whether "Save" means save-and-close, save-and-next, or save-and-go-back. It targets a recurring complaint in internal tools and removes a "user-customizable forms" item from our build queue at near-zero infrastructure cost: by default nothing is written to the database, and per-user persistence is a single opt-in flag. Risk is contained because it is additive UI, not a change to how data is validated or stored.

For engineering: Adopt via the HasFormSettings trait on selected form pages, or ->globally() for a broad rollout; start on session storage, then enable ->persist() plus the accompanying migration once we've validated the interaction model. The surface is small and legible: field visibility, drag-order (mapped to tab order), single autofocus entry point, submit-action selection with cmd+enter, presets, and reset. Two caveats to plan around: it's v0.1.0 pre-1.0, so pin the version and expect API churn; and the release evidence is manual browser QA (happy paths across hide/reorder/entry point, all six submit actions, DB round-trips, dark/light, presets, reset, zero console errors, all requests 200/304) rather than an automated suite. Before broad rollout we should add our own feature tests around persistence, confirm authorization/multi-tenant scoping on the settings table, verify accessibility of the gear dropdown and drag controls, and check the i18n path if we need locales beyond German and English. Recommend a scoped pilot on one or two internal forms, with a go/no-go on promoting to DB-backed persistence.