Immigration Case Management Software Problems: The 7 That Cost Work Authorisation, and How to Avoid Them

Why does the deadline engine get scoped as a date field so often?

Because the requirement arrives in writing as track expiry dates, which sounds exactly like a column. A developer hears it, draws a case table with a due date, and everyone agrees it is straightforward. Then the work meets the domain.

An H-1B extension can be filed up to six months before current validity ends, so the task to start gathering evidence has to fire long before the date anyone wrote down. The six year limit interacts with AC21: a labour certification pending 365 days or more buys one year increments, an approved I-140 with a priority date that is not current buys three year increments. A termination starts a 60 day grace period. A material change in worksite triggers an amended petition, which has been the position since Matter of Simeio Solutions. None of that is a date a human types. All of it is a computation over documents you already hold.

The fix is structural and it has to be decided before the first schema is written. Store the source notice. Extract validity dates from it. Derive every downstream deadline from a rule attached to the status type, and recompute the whole chain whenever a new document lands. Alerts fire at 180, 120, 90, 60 and 30 days against the derived date. The acceptance test is one sentence: when a notice grants less time than was requested, the entire schedule must move on its own. If a human has to go and edit anything, the model is wrong and you will find out later at someone's expense.

What goes wrong when a decade of cases moves out of INSZoom or Edge?

Migration is where these projects slip, and it slips for a reason that is specific to immigration rather than generic to data. Incumbent exports are shaped around cases. The model you are moving to is shaped around a person with a continuous authorisation history. Those are not the same object and no script converts one to the other.

The same individual shows up three times under three employers, sometimes with different spellings of a name and different date of birth entries. Gaps between an approval expiring and the next one starting may be a genuine break in status, a change of employer with portability, or a data entry error from 2018, and only a human who knows the file can say which. Receipt numbers frequently live in free text notes rather than a field. Attachments export without the metadata that told you which filing they belonged to.

What works is a sequence rather than an event. Migrate active and recently closed matters first, because those are the ones that carry deadline risk and the ones your team can still adjudicate from memory. Run both systems in parallel for one full filing cycle so discrepancies surface while the old system is still authoritative. Bulk load the archive afterwards, accepting that older records will be thinner. Settle export rights with your incumbent before development starts, not in month four, because that negotiation has its own timeline and it is not yours to control.

Why do the HRIS and government portal integrations break after launch?

They break for two unrelated reasons, and conflating them is why teams budget for one and get hit by the other.

On the HR (Human Resources) side, the integration works perfectly until the organisation changes. Someone adds a legal entity after an acquisition, renames a worksite field, or restructures job codes. A direct field mapping to Workday, SuccessFactors or BambooHR then stops matching, and the failure is silent: termination events simply stop arriving and the 60 day grace clock never starts for anyone. Nobody notices, because an absence of alerts looks identical to a quiet month. The defence is to treat the HR feed as an inbox rather than a pipe. Every inbound event is recorded, events that cannot be matched to a person go to a review queue instead of being discarded, and a drop in expected event volume raises an alert on its own.

On the government side, the problem is that FLAG and myUSCIS were never built for you to integrate with. There is no friendly public interface, and any developer promising deep portal automation should be asked to explain the mechanics before you believe it. The two jobs that genuinely matter are ingesting notices and checking case status. Build both around documents arriving in a monitored inbox, with extraction pulling receipt number, notice type and validity dates, rather than around a scripted session that a login change will break during your busiest filing week.

What happens when the public access file is not covered?

The labour condition application rules require the public access file to be available within one working day of filing. It holds the certified application, the wage rate, the actual wage memorandum, evidence that notice was posted, and a summary of benefits. In practice, at most firms and most employers, none of this exists as a file. It exists as an intention.

The file gets assembled during a Department of Labor investigation, from memory, three years after the fact, for a worksite the company vacated. Somebody hunts for a posting photograph that was never taken. The benefits summary is reconstructed from a plan document that has since been replaced. The underlying filing was correct and the wage was right, and the exposure is entirely about evidence.

A build makes the file a byproduct instead of a task. Certifying an LCA triggers assembly. Posting notices are generated with the correct worksite address and posting window, and their completion dates are recorded when someone marks them done rather than assumed. The benefits summary is pulled from the employer record, which is versioned, so the version in force at filing time is the one attached.

Scope this in the first release. Retrofitting it means backfilling files for filings already made, which is manual work you cannot automate because the evidence for those was never captured. Confirm your specific retention obligations with immigration counsel, since they vary with circumstance.

Should you build custom or configure what you already own?

A fair number of readers should not build, and we would rather say so here than after a discovery workshop.

If you are a firm under roughly 200 concurrent cases with a conventional petition mix, Docketwise will serve you and its form filling is genuinely fast. INSZoom and LawLogix Edge carry deeper form libraries and questionnaire flows, and a mid sized practice doing standard petition work gets filings out the door with either. Tracker Corp is the sensible choice for a corporate team that wants immigration and I-9 administration in one place. At that scale a custom build is an expensive way to obtain the same forms.

There is also a harder version of this advice. For a meaningful number of practices, the real problem is docket discipline rather than software. If your paralegals apply different lead times for the same status type and nobody owns the rules, a new system loaded with the same typed dates will produce the same misses on nicer screens. Fix the rules first and you may discover the tool was never the constraint.

Build when two or more of these hold. You carry more than 300 concurrent cases and your deadline safety depends on one person's diligence. You are an employer sponsoring 150 or more people and need immigration status joined to headcount, wage bands and worksite records inside your own systems. Your practice sits in a niche such as cap exempt research employers or entertainment visas where the packaged questionnaire flow fights you. Or you have been through a DOL or ICE inspection and improvised your way through it.

How do hidden costs get into the quote?

Form count is the first and the largest. The I-129 with its H classification supplement, the ETA-9035, the ETA-9141, the ETA-9089, the I-140, the I-485, the I-765, the I-131 and the G-28 are nine separate mapping and validation exercises, not one feature called forms. USCIS retires editions and rejects filings submitted on an expired one, so each form also carries an ongoing maintenance obligation that belongs in the running cost rather than the build. Ask for pricing form by form and watch what happens to the number.

Third party placement work is the second. Itineraries, end client letters and multi site documentation multiply the evidence model, and a quote written against direct employment will not survive contact with a staffing client.

Multi entity employers are the third. Different employer identification numbers, different worksites and different signatories mean the employer record is a hierarchy rather than a row, and that decision cascades through every generated form.

The fourth is not engineering at all. Agreeing the deadline rules routinely takes two to three weeks before a single rule is coded, because firms discover their own staff disagree about lead times. Budget it, start extracting the rules before development begins, and treat the parallel filing cycle during migration as real cost rather than contingency.

What separates a build that works from one that fails here?

Ask the developer to model status on a whiteboard before you sign anything. The right drawing is a person with a sequence of authorisation periods, each carrying a basis, a source document and a derived expiry, with dependent statuses hanging off it. A developer who draws cases with a due date field has built a task tracker and is about to learn immigration on your budget.

Ask what happens when a notice grants less time than requested. That single scenario tests whether dates are derived or stored, and there is no way to answer it well without having done the work.

Ask what happens when HR renames a field. The answer you want mentions unmatched events, a review queue and volume alerting, not a promise that the mapping will be correct.

Ask who owns the repository, the cloud accounts and the unrestricted right to hire someone else, and get it in writing before kickoff. At Digital Heroes the client owns the code from the first commit. In a system that holds data about people's right to work and their families, a vendor holding your schema is holding power over an obligation you cannot pause.

Then do the operational half. Name one owner for the deadline rules. Review overrides monthly. Software prevents the mistakes it was told about, and someone has to keep telling it.