Filament Drafts Laravel Package

Product Decisions This Supports

• Build vs. buy for editorial workflow. Draft/publish separation, revision history, and rollback are recurring asks anywhere non-engineers edit live content. This package reframes a multi-sprint custom build as a dependency decision — roughly a one-to-two-week integration on the first resource, materially less on each subsequent one. That frees delivery capacity for differentiating work.
• Whether Filament can be the back-office backbone. If drafts and revisions are the last capability blocking Filament from replacing a heavier CMS for internal tools, this closes the gap at low cost and defers a platform migration by at least a release cycle.
• Feature scoping across content-adjacent surfaces. Marketing pages, help center articles, policy and legal copy, product descriptions, and internal wikis share one editorial pattern. Committing to a single draft/revision primitive early lets those surfaces ship consistently instead of each team inventing its own is_published flag.
• Governance and auditability posture. Revision history answers "who changed what, and can we restore it?" — a question that shows up in regulated content and any review/approval workflow. This informs whether model-level history is sufficient or a dedicated audit solution is required.
• Risk reduction on live content. A draft-first editing model shrinks the blast radius of an accidental publish. That is a product-risk decision as much as an engineering one; adopting a proven pattern is cheaper than retrofitting one after an incident.
• Roadmap sequencing for editorial capabilities. Previews, scheduled publishing, and multi-stage approvals can all be layered on a drafts/revisions foundation. Knowing this primitive exists changes what editorial features can credibly be promised, and in what order.
• Where to spend review budget. The real long-term cost is not the install — it is the discipline of keeping each base table and its shadow draft table in lockstep. This is a decision to own a convention (plus a CI schema-diff check), not to write feature code.
• Where not to spend it. Because the abstraction is thin (~300–500 lines of equivalent in-house code), the build-vs-buy answer flips toward build if the content model is relationship-heavy or the roadmap includes Filament v4 soon.

When to Consider This Package

Adopt when most of the following hold:

• The product runs on Laravel + Filament v3, and the models needing drafts are ordinary, flat-schema Eloquent resources managed through Filament admin panels.
• Non-technical editors are the primary users and need safe edit/publish separation plus a preview of unpublished changes before they go live.
• The editorial workflow matches the happy path: per-record draft state, a single publish action, no complex multi-stage approvals or per-field merge rules.
• You can afford to pin the exact version (2.1.1), commit the lockfile, and assign a named owner for a few hours per quarter — this is a single-maintainer, zero-dependent package with no production evidence behind it.
• The team accepts the schema-drift convention: every future migration on a drafted model becomes a two-table change with a CI check and a PR-template item.

Look elsewhere — or build the thin in-house equivalent — when any of these are true:

• Relationship-heavy content models. Draft tables carry columns, not relationship graphs. Many-to-many pivots, media attachments, and nested repeaters are unproven here and are the classic source of silent content loss on publish.
• Filament v4 is on the near-term roadmap. This is v3-era code and plugins are effectively version-locked; adopting it pins your admin panel upgrade path.
• Regulated audit requirements. Revision history here is operational convenience; it is not a compliance-grade audit trail with immutability guarantees. Verify publish transaction semantics yourself before trusting side effects.
• Unique constraints on shared fields (e.g. a unique slug) that collide between live and draft rows and would force a rule change you are not prepared to make.
• You want zero-maintainer risk. Forking is viable given the small surface area, but budget for it explicitly rather than assuming upstream will fix issues.

How to Pitch It (Stakeholders)

For executives — one line: A small, low-cost plugin that lets non-technical editors stage and preview content changes before they go live, so we can close the "we need drafts" gap in our admin tooling this quarter instead of committing a sprint to build it, and instead of migrating to a heavier CMS.

The trade we are making: We accept a maintenance convention — mirrored draft tables and an enforced schema-drift check — in exchange for not owning an editorial workflow implementation. We also accept a version pin and a documented upgrade constraint around Filament v4.

For engineering — what it actually is: A thin Filament v3 plugin that adds a parallel draft table per model, a reusable trait, publish actions, and revision records. Value comes from the pattern, not the code volume; the trait is roughly 300–500 lines of equivalent in-house work. So the decision is really: adopt the convention, or write it ourselves. Either way the schema-discipline cost is identical.

Rollout ask:

1. Integrate end-to-end on one low-risk, non-customer-facing resource (a Page or Announcement), with a feature test on all four publish semantics, before touching a second model.
2. Wire separate authorization for drafting vs. publishing — this is the governance win and it is nearly free.
3. Backfill all existing rows as published before editors see the UI, or the entire content archive will appear as unpublished drafts.
4. Let editors use it for one release cycle, then repeat the now-mechanical per-model checklist.

What we will measure to decide whether to keep it: time-to-integrate the second and third resource, count of schema-drift incidents caught in CI, editor-reported publish errors, and whether the draft model forces any content model to be redesigned. If relationship-heavy models become the majority of the backlog, that is the signal to reassess.

Known constraints to record in the ADR: single maintainer, zero dependents, last meaningful release 2023, French localization only (confirm other locales before promising translated UI), revision-table growth needs scheduled pruning, and Filament v4 support is unverified — plan for a fork if v4 lands on the roadmap.