Filament ImportAction: skipping duplicate keys without aborting the whole import

Question

I'm using Filament's built-in ImportAction (Filament v3) to restore records from a CSV export, mapping columns to model attributes through the standard column-mapping closures. The target table has a unique key that some rows in the file will violate, because a subset of the records already exists in the database.

From what I can tell, the import runs inside a single database transaction, so when the database raises a duplicate-key exception the entire job fails and every previously imported row is rolled back. For a large restore file that means one conflicting row discards thousands of valid ones. I also see a shouldImportRow-style per-row callback mentioned in the docs, but I can't find clear guidance on whether skipping a row there is the intended way to tolerate duplicates, or how it interacts with the transaction boundary and the failure reporting.

My constraints: I need a partial import (skip conflicting rows, keep the rest), and I want a reliable way afterward to verify which rows were actually persisted versus skipped.

Questions:

Is there a supported configuration to make ImportAction skip duplicate-key rows and continue, rather than aborting the transaction?
Does filtering duplicates in the per-row validation callback guarantee the remaining rows commit, or can a later failure still roll everything back?
What is the recommended way to get a per-row record of skipped duplicates for post-restore verification?

Tasadduq Burney · Answer

Confirmed factsFilament’s ImportAction executes the entire CSV import inside a single database transaction. If any row triggers a duplicate‑key exception, the transaction is rolled back, discarding all previously inserted rows.The shouldImportRow callback runs for each row before the insert attempt. Returning false skips that row and prevents the insert, so no duplicate‑key exception is raised for that row. However, the callback still runs inside the same transaction; a later row that does cause a duplicate‑key error will still abort the whole transaction.Likely explanationTo achieve a partial import you must prevent the duplicate‑key exception from ever occurring. That means detecting existing rows yourself inside shouldImportRow and skipping them before the insert is attempted.Steps needed for this caseIdentify the column(s) that make up the unique key on the target table (e.g., email or a composite of user_id + slug).In your ImportAction definition, implement shouldImportRow to query the model for an existing record using those columns. Return false when a match is found.Ensure no other validation or later processing step can throw an exception (e.g., custom mutators, observers) that would still cause a rollback.Optionally, use the afterSaved or import completion hook to collect the IDs of rows that were actually persisted.After the import finishes, compare the set of persisted IDs (or any unique identifier you stored) with the original CSV row identifiers to determine which rows were skipped.Missing diagnostic detailTo confirm that the duplicate‑check in shouldImportRow will work reliably, please specify which column(s) constitute the unique constraint you are trying to avoid violating.

Filament ImportAction: skipping duplicate keys without aborting the whole import

1 answer

Confirmed facts

Likely explanation

Steps needed for this case

Missing diagnostic detail

Your perspective belongs here.

0 question comments