Filament Mail Templates Laravel Package

Product Decisions This Supports

• Build vs. buy for editable transactional email. This package replaces hardcoded Blade mail views with a database-backed, admin-editable template resource inside Filament. The buy decision is easy to justify: the alternative is a custom CRUD screen plus variable substitution, preview, and locale handling that someone has to own forever.
• Roadmap: localized transactional email. v2.2.0 adds support for translatable-tabs v3, which means per-locale templates are a supported path rather than a fork. If multi-language customer email is on the roadmap, this release is what unblocks sequencing it.
• Feature: decoupling copy changes from deploys. Subject lines and body copy can be changed by support/ops/marketing without an engineering release. That is a recurring velocity tax removed, not a one-off feature.
• Use cases to scope: onboarding sequences, password resets, receipts and order updates, notification digests — anywhere content churns faster than code.
• Upgrade sequencing. Because v2.2.0 is a compatibility release tied to translatable-tabs v3, it answers a concrete planning question: whether we can adopt the newer tabs package without forking this one. It does not signal an API redesign or migration project.

When to Consider This Package

Adopt when:

• The stack is Laravel + Filament and Filament is already the admin surface — no new UI for anyone to learn or maintain.
• Non-developers need to edit email content, and template content should live in the database with seeded defaults rather than in version-controlled Blade files.
• Per-locale templates are required, and you are on (or willing to move to) translatable-tabs v3, which v2.2.0 explicitly supports.
• Copy churn is frequent enough that "change a sentence = open a PR" is a measurable bottleneck.

Look elsewhere when:

• You are not on Filament. The plugin is a Filament resource; a Nova, Inertia, or custom admin gets little from it.
• You need a sending platform — segmentation, scheduling, deliverability, analytics. This manages templates; it is not an ESP and does not replace one.
• Copy requires formal approval/compliance workflows beyond a simple admin edit; you would end up wrapping your own state machine around the model regardless.
• You are pinned to translatable-tabs v2 and cannot move yet — stay on 2.1.x rather than force a paired upgrade mid-cycle.
• The surface area is tiny. One or two rarely-changed templates are cheaper as Blade views than as a dependency plus its upgrade cadence.

How to Pitch It (Stakeholders)

For executives: A small, low-risk dependency that lets non-engineers change customer-facing emails without an engineering release — faster copy turnaround, fewer deploys for content-only changes, and no bespoke admin screen to build or staff. This release (v2.2.0) is a maintenance/compatibility update: it aligns us with the current version of a companion library and carries routine CI dependency bumps. No breaking changes, no migration work implied on our side.

For engineering: Filament plugin; templates are Eloquent-backed and edited through a familiar resource UI. v2.2.0 adds translatable-tabs v3 support (PR #36) and bumps actions/checkout 6→7 via Dependabot — a patch/minor-shaped change with no deprecations or API changes called out. Recommended posture: adopt with a ^2.2 constraint if you are on translatable-tabs v3; if you are still on v2 of that package, hold at 2.1.x and plan the two upgrades together. Keep seeded templates in version control so content is reproducible across environments, and treat the template model as the source of truth in tests rather than asserting against rendered mail output.