Filament Quick Add Select Laravel Package

Product Decisions This Supports

• Admin/back-office UX investment: form completion speed. Every relationship Select that requires "search → miss → open modal → fill → submit → re-find → select" adds a multi-step detour to high-frequency data entry. This package collapses that to one click. It's a cheap, low-risk way to test whether friction in operator workflows is actually costing us throughput, before committing to a larger internal admin redesign.
• Build vs. buy for micro-interactions. A one-line ->quickAdd() on an existing Filament Select replaces what would otherwise be a custom field component, internal forked Select, or a sprint of front-end work. The decision is essentially: adopt a 200-line MIT macro now, or defer the feature indefinitely because it never wins a prioritization slot.
• Roadmap sequencing for "master data capture." If we know our category/tag/skill/profession lists are chronically incomplete (operators pick the closest wrong option or abandon the field), this is the enabler that lets us defer a formal taxonomy-cleanup project. It also gives us a cheap read on what users are typing that doesn't exist — a direct feed of vocabulary gaps into the master-data backlog.
• Scope decision on inline record creation. The package draws a clear line: it creates records with only the title attribute populated. This forces a product decision per entity — which lookups are safe to create inline (tags, skills, categories) versus which must keep the full createOptionForm() modal (anything with required fields, codes, owners, effective dates, financial or regulatory attributes). Treat that as a per-field classification exercise, not a global toggle.
• Governance and permissioning decisions. The enabled: closure (auth()->user()->can('create', Category::class)) means inline creation can be gated by existing Filament policies rather than a parallel permission system. That supports a decision to roll out to a pilot role/team first without new authorization plumbing.
• Localization and audience decisions. Shipped translations (EN, FR, DE, ES, ID, IT, PT, AR) mean this can go to non-English back-office teams without us owning copy. Custom label templates let us tune the prompt to match our voice per entity.
• Reversibility as a decision lever. MIT license, no data migration, no schema change, no lock-in — the "undo" cost is deleting a method chain. That lowers the bar for a time-boxed experiment where a paid product or custom build would need a business case.

When to Consider This Package

Adopt when:

• The stack is Filament 4 or 5 on Laravel 11–13, PHP 8.2+ — the package tracks these actively (Filament 5 and Laravel 13 support shipped in point releases), so version fit is a real gate, not a formality.
• The pain is concentrated in high-volume, low-ambiguity lookup fields: tags, skills, categories, professions, simple taxonomies. These are exactly the entities where "name only" creation is acceptable.
• You want a time-boxed experiment with a measurable hypothesis (form abandonment on the field, median time-to-complete, count of new records created inline) rather than a committed feature.
• Engineering has appetite to own it. With 18 stars, zero dependents, and a single maintainer, the realistic posture is "vendored dependency we can patch." The code is small and the mechanism is documented (macro over Filament's Select), so that's tractable — but it must be a conscious choice, not an assumption of vendor support.
• Users are internal/trusted operators. Inline creation is a write path with no confirmation step and no validation beyond the search string.

Look elsewhere (or build) when:

• The field is options-based rather than relationship-based — explicitly unsupported.
• The related model needs more than a title to be valid or useful: workflow states, uniqueness constraints beyond name, tenant/org scoping, or anything an auditor would ask "who approved this and when" about.
• Duplicate and near-duplicate risk is material. Quick add makes it trivially easy to create "Marketing", "marketing", and "Mktg" in a single session. If the lookup feeds reporting, segmentation, or billing, the cost of taxonomy drift likely exceeds the entry-speed gain — or you need dedupe/merge tooling first.
• You need SLA-backed support, security review, or a maintenance contract. Nothing here suggests that exists; plan for the upgrade-fragility risk of a macro that hooks Filament internals across major versions (a Filament 5 → 6 upgrade is a likely break point).
• You require audit trails or approval flows on inline creation — that's a createOptionForm() plus policy conversation, not this package.

How to Pitch It (Stakeholders)

For executives — one paragraph: Our Filament admin panel makes operators stop, open a modal, and lose their place every time they need a lookup value that doesn't exist yet. This is a free, MIT-licensed, one-line extension that lets them create and select that value inline, in the same dropdown, with no interruption. There is no schema change, no data migration, and no vendor commitment — the entire change is a method call we can remove in minutes. Total cost is an afternoon of engineering plus a policy check on which lookups are allowed to be created inline. I'd like to run it for four weeks on a pilot team and decide on expansion based on time-to-complete and count of inline creations, not on opinion.

For engineering — the ask: Add cocosmos/filament-quick-add-select and apply ->quickAdd() to a short, reviewed allowlist of relationship selects. Gate each with enabled: fn () => auth()->user()->can('create', Model::class) so it inherits existing Filament policies. Pin the version and vendor it, because the package is a single-maintainer macro over Filament internals with 18 stars and we should assume we own the fix. Wrap adoption behind our own form-builder helper so a future Filament major upgrade or a switch to a native implementation is a one-file change. Add a regression test asserting that quick-add fields still respect policies and that created records are title-only by design.

Anticipated objections and the answers:

• "It's an unmaintained tiny package." — Correct framing: it's small enough to own. We pin, vendor, and absorb it behind an abstraction. The alternative is building the same behavior ourselves.
• "Won't users create junk data?" — Yes, for some entities. That's why this is a per-field allowlist, not a global switch, and why the pilot measures what gets created. The vocabulary-gap signal is arguably worth more than the speed gain.
• "What if it breaks on the next Filament upgrade?" — It's isolated to specific fields behind our wrapper; worst case we revert those fields to modals and lose nothing but the experiment.