Laravel Model Flags Laravel Package

Product Decisions This Supports

• Idempotent one-off jobs and backfills: The clearest product win is safely re-running bulk operations (promotional emails, data migrations, entitlement grants, notification rollouts) without duplicating side effects. This lets a PM greenlight "run it, watch it fail halfway, re-run it" operational plans instead of building bespoke checkpoint tables or manually tracking progress in spreadsheets.
• Feature rollout and lifecycle gating: Per-record flags make it cheap to mark cohorts (e.g., "user saw the new onboarding", "account migrated to v2 billing", "record reconciled") without adding a column to every domain table. Supports beta cohorts, staged rollouts, and "has completed X" product states that are operational rather than core-domain.
• Build vs. buy: A flags table plus trait is roughly a half-day of engineering plus ongoing migration debt for each new boolean. With 454 stars, MIT license, an actively maintained Spatie release train (Laravel 11/12/13 support, enum support, lastFlaggedAt, array unflagging), and zero infrastructure cost, this is a clear "buy" — the build decision is only defensible if flags must live in the same table as domain state for query performance or reporting.
• Roadmap sequencing: Because flags require no schema migration per use case, teams can ship experimental state tracking this sprint and promote a flag to a real column later once the behavior proves out. This lowers the cost of "try it and see" product bets and reduces commitment to speculative columns.
• Instrumentation for audits and support: lastFlaggedAt() gives lightweight "when did this last happen" answers for support and CS without a full event/audit pipeline — useful for triage tooling and customer-facing status.

When to Consider This Package

• Adopt when: you need transient or operational per-record booleans that don't belong in the domain schema; you're writing Artisan commands or queued jobs that must be restartable; you want query scopes (flagged / notFlagged) to drive batch selection; you're on Laravel and already accepting Spatie as a trusted vendor.
• Look elsewhere when: flags are core business state queried in hot paths at high volume — a joined flags table adds a join and index pressure versus a native boolean column; when you need rich metadata, actor, or reason per flag (this stores a name and timestamps only); when you need flag evaluation for A/B assignment or percentage rollouts (use a feature-flag service or LaunchDarkly-style tool, not this); when you need historical/append-only audit trails of every state change; or when you require strict type safety across many flags — stringly-typed flag names invite typos, so prefer enums (supported) and enforce naming conventions in code review.
• Caveats to price in: the package depends on a single flags polymorphic table shared across all models, so high-volume flag tables become a shared scaling concern; flag cleanup on model delete is handled, but stale flag names across the codebase are not — you'll want a documented registry of allowed flags. Low dependent count (0) reflects that it's a small utility rather than a widely-forked ecosystem piece; treat vendor-abandonment risk as low given Spatie's track record but pin the version and be ready to vendor the trait (it's ~200 lines).

How to Pitch It (Stakeholders)

To executives: This is a small, free, MIT-licensed utility from Spatie that lets us record per-record state — "this customer got the email", "this account finished migration" — without database changes for each new case. It directly reduces the cost and risk of running large customer-facing batches, because those jobs become safely restartable: if a job dies halfway, we re-run it and only the remaining customers are touched. That means fewer duplicate emails, fewer double-credits, and less engineering time building one-off tracking. Expected effort is hours, not weeks, and there's no new infrastructure or vendor contract.

To engineering: Add the package, publish the migration, and use HasFlags on models that need it. You get flag(), hasFlag(), unflag(), flagNames(), lastFlaggedAt(), and flagged/notFlagged scopes backed by a single polymorphic flags table. Use enums for flag names to get some type safety; keep a registry of flag names to prevent drift. It's not a feature-flag system and not a substitute for real domain columns on high-traffic query paths — treat it as operational bookkeeping for idempotent jobs and lightweight lifecycle markers. Active maintenance is confirmed through Laravel 13, so keep it current and pin the minor version.