Separate identity from a changing filename
A human-readable filename is convenient, but it may change when a person renames a document or uploads a revision. If other records store that name as the object's identity, each rename can require coordinated updates. Consider assigning a stable identifier to the logical file and keeping the display filename as metadata that can change independently.
Choose a key format that fits how the application retrieves files. A prefix can group related objects, while a stable identifier distinguishes one object from another. Avoid putting unnecessary personal or confidential information in names that may appear in logs, exports, or links. Keep the convention documented so different parts of the application construct the same reference.
Define how replacements are handled
Decide whether a revised file should replace the content at an existing key or receive a new key. Replacing content preserves the reference but can make older records appear to point to newer material; creating a new key preserves history but requires updating the record that identifies the current file. The right choice depends on whether your application needs version history or only the latest content.
Test the full lifecycle: create the object, save its reference, retrieve it, replace or rename it, and remove it when no longer needed. Verify that related database records and workflows still point to the intended file after each operation. A consistent identity policy prevents broken references as the application evolves.