Filing conventions read like housekeeping. They stop being housekeeping the first time one of three things happens.
A client in a family application asks for their own separate file. A partner matter becomes a dispute and the two clients' interests diverge. Or the Authority asks you to produce a file, whole, and you discover it was never one thing.
The Code of Conduct anticipates the first of those explicitly, and a convention that cannot absorb it will have to be rebuilt under pressure.
The unit the Code cares about is the client file
Section 56(1) requires a client file to be created and maintained for the client. Section 56(3) then allows a single file to cover two or more clients who are members of the same family unit — other than a client who requests the agent to create and maintain a separate client file for them.
Three consequences for how you organise things.
The default unit is the client, not the application. A client with a bridging visa, a substantive application and a later citizenship matter has one file with a continuous history, not three unrelated folders.
The family concession is a permission, not the structure. You may keep one file for a family unit, but any member can ask for their own — and if the convention only knows about "the Nguyen matter", satisfying that request means unpicking a shared file into per-person files after the fact.
And section 56(4) settles a question people still ask: a client file may be kept in written or electronic form, or partly written and partly electronic. There is no requirement for paper, and no requirement for one system.
Name the client, then the matter
Most practices name the folder after the visa. It is the wrong way round, because the client persists and the visa does not.
A convention that survives both audits and staff turnover has four parts:
- A stable client identifier that never changes. Not the name, because names change on marriage, on transliteration, and on the discovery that the passport spelling differs from the one used at intake.
- The client's name as it appears on the passport, because that is what every government document will use. Where a client uses a different name day to day, record both and make both searchable.
- The matter, expressed as what it is rather than what stage it is at. "482 nomination" not "in progress".
- The date it opened, which makes chronology visible without opening anything.
Two rules matter more than the format you choose. Sort order should follow chronology, which means dates written year-first. And status should never live in the name, because status changes and renaming breaks every link, reference and shortcut pointing at it.
Names have to work for the whole team
A convention that only the person who wrote it can apply consistently produces a filing system with two dialects.
Test it by having someone else file five documents. If they hesitate about where something goes, the convention is under-specified, and under-specified conventions decay into personal habits within a month. OMARA's guidance on practice management duties lists ensuring all client contact is recorded on the client file among the arrangements that discharge an agent's duty over others' work — which is only achievable if everyone agrees where the file is.
Filing that mirrors what the file must contain
The most useful structure is not the one that feels tidy. It is the one shaped like the list you would be asked to produce.
Section 56(2) requires the client file to contain the application or other immigration matter, all service agreements and variations, all written communications including electronic ones, contemporaneous records of oral communications with the client, records of material oral communications with third parties, all invoices and receipts, copies of the client's personal documents, and evidence of the safe return of originals.
Build folders that map onto those categories and producing the file becomes trivial. Build folders around workflow stages — "to do", "waiting", "sent" — and you have organised the work rather than the record, which means assembling the file later from memory.
Two categories are almost always missing in practices that organise by stage: third-party oral communications (the call to the case officer) and evidence of returning originals. Neither has an obvious home in a stage-based structure, so neither gets one.
Versions, and the document that must not be ambiguous
Version control matters most for two things: the application itself, and the service agreement.
For applications, the risk is lodging a superseded draft. For agreements, the risk is being unable to say which version was in force when the work was done — which matters because section 42 requires a compliant agreement to be in force, and any variation to have met section 44's requirements.
Three rules cover it:
- Never overwrite a signed document. A signed agreement is a record, and a variation is a new document, not an edit.
- Mark drafts as drafts, and finals as final, in the filename — not only in a properties field nobody reads.
- Keep what was sent, distinct from what exists now. The version the client received is the evidentially significant one.
Where naming meets retention
Retention is keyed to the last action on the file, and the destruction date moves whenever the file is touched. That only works if the system knows what the file is.
A matter scattered across a shared drive, a mailbox and a signing tool has three different "last actions" and no single retention date. Our guide to client file retention covers the obligation; the point here is that a filing convention is what makes it computable.
Migrating an existing mess
Nobody starts from nothing. The usual position is years of accumulated folders under three or four conventions.
Do not attempt a full retrospective rename. It is a large project with no client benefit and a real risk of breaking references.
- Apply the new convention to new matters from a fixed date.
- Convert a file when you next touch it, so active work migrates naturally and dormant matters stay where they are.
- Build an index rather than moving everything — being able to find a 2021 matter matters more than it being named correctly.
- Leave closed matters alone, unless one is reopened.
Our guide to the first 48 hours of onboarding covers where the convention is applied in practice, and our guide to starting a migration agency covers setting it up before the mess accumulates.
The filing test
- Can a new staff member file five documents without asking?
- If a client in a family matter asked for their own file, could you produce one?
- Where do third-party call records live?
- Where does evidence of returning originals live?
- Can you tell which version of an agreement was in force last March?
- Does any folder name contain a status that will change?
- Could you produce one complete file from one place?
Where a system helps
Filing conventions are documentation of a problem you should not have. They exist to compensate for storage that has no idea what a matter is.
When documents attach to a matter rather than to a folder path, most of the convention becomes unnecessary: naming is metadata, the client-versus-matter question is a relationship rather than a directory, a family unit can be one file with per-client views, and "the last action on this file" is a fact rather than an inference.
LodgeHQ models clients, matters and documents as related objects, so filing is a consequence of doing the work. Start a free trial and see how much of your convention you still need.
Verify before you rely on it
The record-keeping provisions changed with the current Code, and a filing structure built around older clause numbering may be organising for a list that no longer applies. Read the current text before rebuilding, and check OMARA's practice management guidance for what supervision of filing is expected to look like.
This is general information for migration practices, not legal advice. Where a client asks for a separate file, or where two clients on one file develop a conflict, get advice on that matter.