What software does an Australian migration practice actually need?

Practices evaluating software for an Australian migration caseload tend to compare products. That is the wrong axis. The tools available do genuinely different jobs, and the more useful question is which category of work you are trying to solve — because the categories have different obligations behind them, and a product that covers several of them well is rarer than product marketing implies.

This page is a vendor-neutral map of the territory: it names no competitor, and the taxonomy below is drawn from the regulator and the Department rather than from any product's marketing. It sets out who may lawfully do the work at all, what the Department's own portal does and does not do, and which categories of tool sit in the space in between. A clearly labelled note on where the publisher's own product fits appears at the end.

1. Two statutory categories of practice, and they are not the same

Before any software question, there is a regulatory one: who may lawfully give immigration assistance in Australia.

“Under section 280 of the Migration Act 1958 (Cth) (the Act) only certain people can provide lawful immigration assistance in Australia. They are: registered migration agents (RMAs) Australian legal practitioners a small number of exempt persons such as close family members of a visa applicant.”

“Immigration assistance is defined under section 276 of the Act and includes a range of activities such as preparing a visa application.”

Two of those categories are businesses that buy practice software: Registered Migration Agents, regulated by OMARA under the Code of Conduct, and Australian legal practitioners, regulated by the legal profession regulator in their state or territory — which in some jurisdictions is a legal services board or commissioner rather than a law society. They are subject to different regulatory instruments and different record-keeping rules, which means they do not always need the same tooling. A product designed for one is not automatically suitable for the other.

“Giving immigration assistance in Australia in circumstances other than that outlined in section 280 of the Act is unlawful.”

2. The lodgement layer: what ImmiAccount does and does not do

ImmiAccount is the Department of Home Affairs' own portal, and it is where most applications are actually lodged. Its scope is narrower than "case management" and worth stating precisely, because vendors frequently imply integration with it.

“ImmiAccount gives you access to many of our online services.”

“You can use ImmiAccount to: apply for a visa or citizenship apply for an APEC Business Travel Card apply for Australian Trusted Trader access LEGENDcom request visitor access to detention facilities create a Visa Entitlement Verification Online (VEVO) account for an organisation access your organisation's education provider report (only if you are a principal executive officer).”

“Do not use ImmiAccount to: apply for an Electronic Travel Authority (ETA) check the status of your citizenship application if you lodged it using forms 1300t or 1290 before 17 April 2015.”

Three practical consequences follow:

• ImmiAccount is a lodgement and account-management portal, not a practice management system. It holds applications, not a practice's client relationships, service agreements, or billing.
• It is the Department's system, and the Department controls it. A practice's own records, workflows, and client communication live elsewhere by definition.
• No public third-party lodgement interface is documented. Material that describes an immigration tool as "integrating with ImmiAccount" should be read sceptically; the honest description of any external tool is that it prepares material for lodgement, then coexists with the portal.

3. The categories of tool between intake and lodgement

Everything else a practice needs is outside the Department's systems. These are the separable categories, in roughly the order work flows:

| Category | The work it covers | The obligation behind it | |---|---|---| | Client intake and enquiry handling | Capturing enquiries, qualifying them, booking consultations | Code duty to give the consumer guide before assistance (s 38) | | Client communication | Corresponding with clients and third parties across email, messaging, and calls | Code duty to keep clients informed (s 39); records of oral communications (s 55) | | Document collection | Getting identity, financial, relationship, and skills evidence from clients and their families | The client file must hold copies of all personal documents supplied (s 56(2)(g)) | | Evidence preparation and verification | Reading what was supplied, checking it against the applicable migration criteria, and finding gaps | Agent remains responsible for the advice and material regardless of how it was produced | | Service agreements and engagement | Producing, signing, varying, and terminating the engagement | Code s 42 contents, s 42(2) signatures, s 44 variations, s 45 completion | | Matter and workflow management | Tracking matters, deadlines, and status across a caseload | General competence and the duty to avoid unnecessary expense or delay | | Billing, fees, and client money | Invoices, receipts, and the handling of client money | Code ss 46–51 | | File records and audit | Keeping the client file in a form that can be produced seven years later | Code s 56 |

Two of these deserve emphasis because they are where practices most often discover a gap:

“A migration agent who has a duty under subsection (1) in relation to a client file must take all reasonable steps to ensure that the client file is kept for a period of 7 years after the last action on the file for the relevant client.”

The seven years runs from the last action, not from lodgement or from the end of the engagement — so the retention clock is driven by activity across all the categories above, not by the application alone.

“A migration agent must make a contemporaneous written record of oral communications between the agent and a client in relation to immigration assistance, including: (a) oral instructions the client gives the agent; and (b) oral advice the agent gives the client.”

This is the category most often handled by a general-purpose tool that was never designed for it. A practice that discusses matters by phone or in person has a record-keeping obligation that a messaging app will not discharge on its own.

4. How to evaluate a product against these categories

Because the categories are separable, a product evaluation should start by asking which ones a given tool actually closes, and how it behaves at the boundaries. Questions that consistently separate tools:

1. Does it hold the record, or merely help produce it? A generator that outputs a document is not a record system unless the document and its history are retained and producible.
2. Can you produce the file for a seven-year-old matter? If retrieving a closed matter is impractical, the retention obligation is unmet regardless of what the product's marketing says.
3. Where does client data go, and who can see it? The Code's duty of confidentiality attaches to what the practice permits, not only to what an individual agent performs.
4. Does it keep the client's consent and the agent's approval? Where AI or automation is involved, the practice needs to show who reviewed an output and what the client agreed to.
5. What happens at the ImmiAccount boundary? The honest answer for every external tool is "prepares for, coexists with". Anything claiming more should be tested against the Department's own description above.
6. Does it distinguish the two statutory practice types? A tool built around the Code's obligations will not fit an unrestricted legal practice's regulatory surface, and vice versa.

Where the publisher's product fits — disclosed vendor note

Everything above is drawn from the regulator, the Department, and the Code. This final section is not neutral: it is the publisher's own note, and it should be read as such.

Immi Flow is built for the first of the two statutory categories — practices operating under the RMA scheme and the Code of Conduct. It covers the pre-lodgement categories above: intake, client communication including WhatsApp, document collection and evidence preparation, service agreements, matter tracking, billing, and the sealed seven-year audit export.

It does not lodge applications and does not replace ImmiAccount. No external tool can, and the Department's description of the portal above — which lists only the Department's own services and no third-party lodgement route — supports that conclusion.

Practice takeaway. The useful question is not "which practice management product is best" but "which categories of work do I need covered, and which of my Code obligations does each one actually discharge". ImmiAccount is the Department's lodgement portal; it does not manage a practice. The rest of the practice — client communication, evidence, agreements, records, and the seven-year file — sits outside the Department's systems and has to be held somewhere that can prove it.