Decide whether a deleted record still owns its unique name
A customer is soft-deleted, then a new customer tries to reuse the same external code. The form says the code is available, but the database rejects the insert. Soft deletion hides a row from ordinary queries; it does not remove its unique index entry.
Choose the business rule first
One valid policy is that an external code remains reserved forever. Another allows reuse after deletion, but then restoration can conflict with the replacement record. Neither policy is solved merely by adding the SoftDeletes trait.
Make the validator, database constraint, restore workflow, and import matching rules agree. If a provider can reuse codes, consider whether a separate immutable provider identifier is the real identity you should store.
Restoration is a write with conflicts
delete customer A → code remains in stored row
create customer B with same code → constraint policy applies
restore customer A → check conflict with B before promising success
Do not remove the unique constraint simply to make the create form pass. That moves the problem into concurrent requests and ambiguous lookups.
Test create-after-delete and restore-after-replacement, not just ordinary soft deletion. Include queries that intentionally use withTrashed for audit or reconciliation. A background import may behave differently from the admin list if one includes deleted records and the other does not.
For customer-facing errors, explain the actual conflict and the available resolution. A generic 500 makes a policy mismatch look like an outage and gives the operator no safe next step.