Filament Translations Laravel Package

Product Decisions This Supports

• Build vs. buy for data in/out of admin panels. Spreadsheet import/export is a recurring ask across nearly every internal tool and back-office roadmap (bulk record creation, customer-facing reports, finance/ops handoffs, compliance extracts). This package turns that from a custom build into a configuration task — the decision it most directly serves is "do we staff a sprint to hand-roll XLSX handling, or do we wire up a maintained plugin?"
• Roadmap sequencing around the Filament/Laravel upgrade. v3.0.0 hard-gates on Filament 5 and Laravel 13. The real product decision is not "adopt this package" but "when do we take the framework upgrade," since this package becomes a dependent item in that migration train (see caveats below).
• Scope negotiation on reporting features. Because export becomes cheap, PMs can say yes to "can we get this data into a spreadsheet" requests that would otherwise be deferred or scoped as custom work — useful for reducing a long tail of small ops requests.
• Internal-tooling investment appetite. This is infrastructure for admin/ops surfaces, not customer-facing product. It's justified when internal tooling velocity is a stated goal; it's a distraction if the roadmap has no Filament-based surfaces.
• Not a differentiator. This does not create user-visible product advantage and should not appear in roadmap narratives or competitive positioning. It's a velocity lever, and should be tracked as such (engineering enablement, not a feature).

When to Consider This Package

Consider it when:

• The product runs on Filament 5 / Laravel 13 — or the team has committed to that upgrade and is planning it now rather than later.
• Import/export is a recurring, repeatable need across multiple admin resources, not a one-off. If you need exactly one export, a small bespoke implementation is likely cheaper than adding a dependency.
• The team is willing to own a transitive dependency: v3.0.0 delegates import/export to cube-agency/filament-excel. That means vetting a second package's maintenance cadence, release history, and license before adoption — not just this one.
• Queued/large-file handling, column mapping, and formatting are real requirements. Those are the parts that are genuinely tedious to build and where a package pays for itself.

Look elsewhere or defer when:

• You're on Laravel 11/12 or Filament 3/4. v3.0.0 is not for you; you'd pin to the prior major line and accept that you're off the maintained path. If an upgrade isn't on the roadmap, this package is a reason to schedule one — or a reason to skip it.
• You need a guaranteed support window or vendor SLA. Community packages with major-version churn and a delegated core dependency don't offer that. If export is on a customer-facing contract with uptime commitments, budget for in-house ownership or a commercial alternative.
• The need is read-only, small, or shape-stable (e.g. one CSV of a single table). A dependency plus a migration burden exceeds the value.
• Licensing terms haven't been checked. Confirm this and cube-agency/filament-excel before committing — this is a blocker to resolve, not a detail.

Migration note if already on v2.x: treat v3.0.0 as a breaking change. The import/export engine is different underneath, so expect behavioral differences in column configuration, disk/storage settings, and queue wiring. Budget a spike to diff behavior against existing exports before the framework upgrade lands, not after — export paths in finance/ops workflows fail loudly and visibly.

How to Pitch It (Stakeholders)

For executives: This is a small, free component that makes spreadsheet import/export in our internal admin tools a configuration job instead of a development project. It removes a recurring class of bespoke work — the "can we get this into Excel" requests that currently consume engineering time across finance, ops, and support workflows. The catch is timing: this release only fits if we're on (or moving to) the newest Filament and Laravel versions, so it's best framed as a sweetener on an upgrade we already need to do, not a standalone initiative. No customer-facing surface area, no revenue impact — value is engineering hours saved and faster turnaround on internal data requests.

For engineering: v3.0.0 is a major bump and a breaking one: it targets Filament 5 / Laravel 13 and replaces the in-house import/export layer with cube-agency/filament-excel. Two things to evaluate before we commit — (1) the upgrade path, including behavioral differences in column mapping, storage/disk config, and queueing against whatever we have today; (2) the health of the new dependency, since we're now inheriting its maintenance and license along with this one. Worth a short spike: verify our expected export/import shapes work, confirm it plays nicely with any custom resources, and check transitive dependency hygiene. If the spike is clean, this is a straightforward win; if we're not ready for the framework jump, we pin to v2.x and revisit.

Recommendation: Adopt if the Filament 5 / Laravel 13 upgrade is on the near-term roadmap and the cube-agency/filament-excel dependency checks out. Otherwise, defer and pin — and log the framework upgrade as the actual decision to make.