Yes — this approach globally hides all “Force Delete” buttons across the entire Filament admin panel.
The solution uses Filament’s configureUsing() method, which is the recommended and cleanest way to modify default component behavior from a single, centralized location.
Below is a breakdown of what each configuration block does and how it affects the admin interface.
1. Hide Force Delete for Individual Table Rows
\Filament\Tables\Actions\ForceDeleteAction::configureUsing(
fn ($action) => $action->hidden()
);
This removes the “Force Delete” button from the Actions column for each individual record in Filament tables.
2. Hide Force Delete Bulk Action
\Filament\Tables\Actions\ForceDeleteBulkAction::configureUsing(
fn ($action) => $action->hidden()
);
This removes the “Force Delete” option from the bulk actions menu, which appears when multiple records are selected.
3. Hide Force Delete from Page Header (Edit / View Pages)
\Filament\Actions\ForceDeleteAction::configureUsing(
fn ($action) => $action->hidden()
);
This hides the Force Delete button from the Edit and View pages of a resource.
Where to Place This Code
This configuration should be placed inside the boot() method of a Service Provider.
Recommended locations:
app/Providers/Filament/AdminPanelProvider.php(preferred for Filament panels)- or
app/Providers/AppServiceProvider.php
Example:
public function boot(): void
{
\Filament\Tables\Actions\ForceDeleteAction::configureUsing(
fn ($action) => $action->hidden()
);
\Filament\Tables\Actions\ForceDeleteBulkAction::configureUsing(
fn ($action) => $action->hidden()
);
\Filament\Actions\ForceDeleteAction::configureUsing(
fn ($action) => $action->hidden()
);
}
Important Notes
Hidden vs Disabled
hidden()completely removes the button from the UI.- The action still exists programmatically and can be triggered manually if needed.
- This is ideal when you want maximum safety while preserving internal control.
Soft Deletes and RestoreAction
If you are disabling Force Delete, it usually makes sense to keep RestoreAction enabled, allowing users to recover soft-deleted records.
If you also want to hide Restore actions, you can apply the same logic to RestoreAction.
About class_exists()
Using class_exists() checks is a good defensive practice to avoid runtime errors if a class is unavailable.
However, in a standard Filament installation, these classes are always present, so the check is optional.
Final Thoughts
This approach gives you:
- Centralized control
- No per-resource configuration
- Clean, maintainable code
- Safer admin UX by preventing irreversible deletes
If you need help adapting this logic for role-based visibility, conditional deletes, or custom policies, it can be extended easily.
