When to Trust Filament's Resource CRUD Generation — and When to Outgrow It

Filament's Resource class can generate a complete CRUD interface — list, create, edit, delete — from a single PHP file and a model. That is genuinely useful, but it also means a lot of behavior is implicit: authorization, query scoping, table performance, and form validation all live behind conventions. This note lays out when the generated Resource is the right design, where its trust boundaries sit, and the checks that tell you it is healthy in production.

Assumptions below: Filament v3 on Laravel 10/11 with Livewire v3. Class names and commands differ in v2; verify against your installed version with composer show filament/filament.

Requirements the generated Resource actually satisfies

The Resource pattern is a good fit when all of the following hold:

• The entity maps closely to one Eloquent model with conventional columns.
• CRUD operations are the dominant interaction — not multi-step workflows or heavy aggregation.
• Authorization can be expressed as model policies (view, create, update, delete per record).
• The table will hold hundreds to low thousands of rows, or you are willing to paginate and constrain columns.

If you need a wizard-style flow, cross-model transactions, or a read model built from joins, the generated Resource becomes a liability and a custom Livewire page is usually smaller.

The smallest suitable design

One Resource class, one model, one policy. Nothing else. Generate the pieces from the project root (any user with write access to the app directory):

php artisan make:model Post -mf
php artisan migrate
php artisan make:filament-resource Post --generate

The --generate flag inspects the table columns and scaffolds form fields and table columns for you. Treat its output as a starting draft: it guesses field types from column types, so review every field before shipping. The resulting class extends Filament\Resources\Resource and declares three things that matter architecturally:

• form() — the write schema. This is your server-side input surface; validation rules here are enforced by Livewire on submit, not just in the browser.
• table() — the read schema, including which columns are searchable, sortable, and filterable. Each searchable/sortable column translates to SQL, so this is also your query-cost surface.
• getPages() — route registration for list/create/edit. No controllers, no routes file entries.

Resist adding custom Blade views or published component overrides at this stage. Every override is code you re-test on each Filament minor upgrade.

Trust and data boundaries

Filament does not invent its own authorization layer — it delegates to Laravel's gates and policies. That is the boundary to get right:

• Define a PostPolicy with viewAny, view, create, update, delete and register it (Laravel 10: AuthServiceProvider; Laravel 11 auto-discovers policies by naming convention).
• Filament calls these policy methods before rendering pages and before executing actions. If no policy method exists for an action, behavior depends on version and configuration — do not rely on a safe default; write the policy explicitly.
• For row-level scoping (e.g., users only see their team's posts), override getEloquentQuery() on the Resource rather than hiding rows in the table. Table-level filtering is cosmetic; query scoping is enforced.
• Field-level visibility can be conditioned with ->visible(fn () => auth()->user()->can('...')), but remember this hides the input — it does not prevent a crafted Livewire request from submitting the attribute unless validation or model $fillable also excludes it. Keep $fillable on the model tight as the last line of defense.

Operational checks

After generating a Resource, verify in this order:

1. Migrations current: php artisan migrate:status — a Resource rendering against a missing column fails at page load, not at generation time.
2. Panel reachable: visit /admin/posts (or your configured panel path) and confirm list, create, edit, and delete all work against seeded data.
3. Authorization enforced: log in as a user the policy denies and confirm a 403, not a silently empty table.
4. Livewire round-trips healthy: open browser devtools, sort a column and submit the create form, and confirm the Livewire POST requests return 200 with no JavaScript console errors. A stale asset build (npm run build not run after upgrade) is the most common cause of silent breakage here.
5. Query cost: with realistic data volume, check the list page's query count (e.g., via Laravel Debugbar or Telescope in a non-production environment). N+1 queries on relationship columns are fixed with ->modifyQueryUsing() eager loading or by selecting relationship columns that Filament eager-loads by convention.

Failure modes

• Large tables: because rendering happens through Livewire round-trips, tables with tens of thousands of rows degrade noticeably. Keep pagination on (the default), avoid ->searchable() on unindexed text columns, and prefer SelectFilter over free-text search where possible.
• Mass assignment gaps: a field present in form() but absent from the model's $fillable is silently discarded on save — the form appears to work but data is lost. Symmetrically, a permissive $guarded = [] plus a hidden field is an exposure. Check both directions.
• Upgrade breakage from overrides: published Blade views and custom field components are the parts that break across minor versions. Keep them minimal and re-test the Resource pages after every composer update touching Filament.
• Policy drift: adding a new action (e.g., a bulk export) without a corresponding policy check can bypass the authorization boundary. Custom actions need explicit ->authorize() calls.

Conditions that would change the design

Move away from the generated Resource when: the write path needs multi-model transactions (extract a service class and a custom page); the list view needs reporting-style aggregation (build a dedicated read model or widget); or non-technical users need guided flows rather than a raw form (use a wizard page). Until one of those is true, the single-Resource design with a real policy and a scoped query is the smallest thing that is still correct.