Laravel Model Flags Laravel Package

Product Decisions This Supports

• Build vs. Buy: Buy – Eliminates the need to manually implement flagging logic (e.g., boolean columns, JSON fields, or custom tables) for idempotency, workflows, or state tracking. Reduces technical debt and speeds up development.
• Feature Roadmap:
  • Idempotent Processes: Enable restartable workflows (e.g., batch email campaigns, data migrations, or cron jobs) without duplicate operations.
  • Dynamic Feature Flags: Toggle features per-user or per-record without migrations (e.g., A/B testing, beta rollouts).
  • Audit Trails: Track when flags were set/updated via lastFlaggedAt() for compliance or debugging.
  • Bulk Operations: Use scopes (flagged(), notFlagged()) to segment models for analytics or targeted actions.
• Use Cases:
  • Marketing Automation: Ensure emails/promotions are sent only once per user (e.g., flag('sent_promo')).
  • Data Pipelines: Skip reprocessing records in ETL jobs (e.g., notFlagged('processed')).
  • Access Control: Replace soft-deletes or complex permissions with flags (e.g., flag('admin_access_granted')).
  • Experimentation: Rapidly iterate on features by flagging users into test groups.

When to Consider This Package

Adopt if:

• Your Laravel app needs lightweight, dynamic state tracking without schema changes.
• You’re building idempotent workflows (e.g., batch jobs, migrations) where restartability is critical.
• You want to avoid migrations for simple boolean-like attributes (e.g., "has completed X").
• Your team prioritizes developer velocity over custom solutions (e.g., no need to build/patch a flagging system).
• You need query scopes to filter models by flag presence (e.g., "find all users without flag Y").

Look elsewhere if:

• You need complex flag hierarchies (e.g., nested permissions) → Consider Spatie’s Laravel-Permission or a custom solution.
• Flags require metadata/values (e.g., flag('premium', 'gold')) → Use a JSON column or a separate flag_values table.
• You’re on Laravel < 8.x → Package supports 8+ (check changelog for your version).
• Performance is critical for high-scale flag operations → Evaluate denormalized columns (e.g., flags_json column) or caching layers.
• You need flag expiration → Extend the package or use a separate flag_expiry table.

How to Pitch It (Stakeholders)

For Executives: "This package lets us turn on/off features or track state for individual records without writing migrations—saving dev time and reducing risk. For example, we can ensure a batch email job only runs once per user, even if it crashes mid-execution. It’s like a lightweight ‘feature flag’ system built into our models, with zero infrastructure changes. Used by teams at [companies using Spatie], it’s battle-tested and MIT-licensed."

For Engineers: *"Pros:

• Zero migrations: Add flags to any Eloquent model with a single trait (use HasFlags).
• Idempotency by default: Perfect for cron jobs, Artisan commands, or data pipelines.
• Query-friendly: Scopes like Model::flagged('x')->get() make filtering trivial.
• Extensible: Supports enums, bulk unflagging, and lastFlaggedAt() for auditing.
• Laravel-native: Works seamlessly with Eloquent, no ORM hacks.

Cons:

• Not for complex permissions (use Spatie’s Permission package instead).
• Flags are global to the app (not tenant-aware by default; can be scoped via middleware).

Example Use Case:

// In a cron job to send welcome emails:
User::notFlagged('welcome_email_sent')
    ->each(fn(User $user) => [
        Mail::to($user)->send(new WelcomeEmail()),
        $user->flag('welcome_email_sent')
    ]);

Result: Users get emails exactly once, no matter how many times the job runs."*

For PMs: *"This reduces friction for time-sensitive features like:

• Launching beta tests (flag users into groups).
• Debugging failed batch jobs (check lastFlaggedAt()).
• A/B testing without code branches. Tradeoff: Simplicity over granularity—ideal for 80% of use cases where flags are binary and app-wide."*