Skip to main content

Collecting documents

Document upload is built into the client intake as an optional step with a checklist specific to the case type — a marriage-based adjustment asks for the marriage certificate and civil documents, while an evidence petition such as EB-2 NIW or O-1 lists one slot per regulatory criterion (recommendation letters, citation record, awards, and so on). Clients can also upload from their portal at any time. Attorneys manage everything from the client’s Documents tab: view, download, upload on the client’s behalf, and track review status per slot. File types. PDFs, photos and scans (JPEG, PNG, WebP, HEIC, TIFF, BMP, GIF), Word, PowerPoint and Excel documents (both the modern and legacy formats), plain-text files, RTF, and ZIP archives. The wider list applies to ordinary client uploads too, not just imports: a client attaching the worksheet they filled in over email is exactly the case it’s there for. PowerPoint, Excel, legacy .doc, ZIP and HEIC/TIFF/BMP/GIF files are stored and downloadable but not read by Lex, previewed inline, or assembled into packets. A ZIP is kept as-is and is never unpacked on the server.

AI document intelligence

When a document is uploaded, Lex automatically:
  • Detects the document type and files it into the right checklist slot.
  • Renames the file to a clean, consistent name.
  • Extracts insights — key fields found in the document are used to fill empty profile fields (existing answers are never overwritten).
  • Works out who the document is about — a spouse’s passport fills the spouse’s details, not the client’s. See below.
Word, text and RTF files are read as text; everything else is read as-is. A file Lex can’t read — a HEIC photo, a PowerPoint deck, a spreadsheet, a corrupt or password-protected document — is still stored and shown as “stored — not read”. It never fails an upload or an import. A file uploaded from the Forms tab’s Import from file dialog is analyzed by the import run itself rather than on upload, so for a moment it may show no analysis status in the library. It ends up classified and renamed like any other upload; the values it holds go to the import’s review sheet, and nothing is filled until the attorney confirms there — see Import from file.

Who a document is about

A case can have several people on it, so Lex decides whose document it is before filling anything. It sends the document’s details to the first match:
  1. The person on the case whose name matches the name printed on the document, when exactly one person matches.
  2. The client, when the document is about the client.
  3. The person holding the role the document belongs to, such as the beneficiary’s passport going to the beneficiary. This applies only to roles one person holds (petitioner, beneficiary, spouse, sponsor).
The details fill that person’s empty profile fields, and their answers land only on form fields that belong to that person. Nothing already filled in is overwritten. Two-person civil records, such as a marriage certificate, fill the case forms they answer without being tied to one person. An uploaded form that’s already filled in, such as an I-130 from another system, is split by role, so the petitioner’s part reaches the petitioner and the beneficiary’s part the beneficiary. When Lex can’t tell, it asks. Lex never guesses. A document about someone who isn’t on the case, a document whose person Lex can’t place, a document about a child or other family member, and a joint sponsor’s I-864 each become a suggestion on the Overview tab’s People card. Add the person (someone already in your firm, or a new person named from the document) and their details are filled in; or dismiss the suggestion. A joint sponsor’s details reach an I-864 once that copy is linked to them.
Two kinds of reading still fill the client’s details only: documents read while importing an existing matter, and the separate documents Lex finds inside one long combined PDF. Add the other people on the Parties tab and fill in their details there.

Document translation

USCIS requires a certified English translation of every foreign-language supporting document. Lex translates a client document in place — any source language, auto-detected — and hands your team a draft to review, correct, and certify. Translating a document. The Translate action appears wherever a document does: in the viewer’s overflow menu, on a document card, and in the table row’s action buttons. It only shows on documents that can actually be translated — an uploaded PDF, photo, or Word/text file that isn’t itself a translation and hasn’t been rejected. Pick a target language (English or Spanish from the list, or type any other language — English is the default) and the translation starts; a new linked row appears under the original with a Translating badge, no refresh needed. Drafts, not filings. The finished translation lands as a Word document nested under its original, marked Draft — visible to your firm only, never to the client. The original gets a “Translated” marker; the draft never enters the approve/reject review queue and is never analyzed as a client upload. If a translation fails, the row shows Failed with a Retry that starts a fresh attempt (the failed row is replaced rather than resurrected). Only one translation per document runs at a time; a second language can be added after the first completes. What the draft looks like. Translations mirror the source’s structure — tabular documents such as civil registry extracts come back as real tables, labels and enumerated values translated, names and ID numbers copied verbatim, checkbox states preserved, blank fields left blank, and seals or signatures noted as bracketed annotations (text the model can’t read is marked [illegible], never guessed). Every translation ends with a Certificate of Translation Accuracy page on its own sheet: the attestation names the detected source language and leaves printed-name, signature, and date lines blank for whoever at the firm signs it. Side-by-side review and certification. On a draft translation (or its original), the viewer offers Review translation — a full-screen review surface with the original in a collapsible pane on the left and the editable translation on the right. Edits save automatically a couple of seconds after you pause typing, with a saving/saved indicator in the toolbar. When the translation is right, Certify — after a confirmation that spells it out — makes it visible in the client’s portal and stamps who certified it and when; the document then opens read-only, showing the certifier and date. Revert to draft (also confirmed) hides it from the client again for further edits. Review runs on desktop-width windows; viewing and downloading translations works everywhere.

Published form versions

When you publish a form version with Save to Documents on, a copy lands in the case’s Documents tab named <FORM> v<n> · <session label> (<YYYY-MM-DD>).pdf. It arrives already approved and is treated differently from an upload:
  • Not analyzed or slotted — Lex doesn’t read it, it fills no checklist slot, and its type can’t be changed.
  • Not in packets — packet assembly fills forms from the live answers, so version copies are left out.
  • Visibility follows the version — the client sees the copy only while the version is Visible to client, and clients can’t delete it.
  • Linked both ways — turning Save to Documents off in the version’s Edit dialog removes the copy; turning it on again makes a new one. Removing the copy here turns Save to Documents off for that version. The version itself is never affected.

Published packet versions

When you publish a packet version with Save to Documents on, a copy lands in the case’s Documents tab named Filing packet v<n> (<YYYY-MM-DD>).pdf. It follows the same rules as a form version copy: already approved, not analyzed or slotted, never offered for or included in a packet, visible to the client only while the version is Visible to client (and not deletable by them), and linked both ways with the version’s Save to Documents setting. The version itself — and its download, filing-packet-v<n>.pdf — is never affected.

Review workflow

Every client-uploaded document goes through attorney review:
  1. Approve — the document is accepted for the case.
  2. Reject with a reason — the client sees the reason and is asked to re-upload.
A few rules keep the record intact:
  • Attorney uploads are auto-approved.
  • Rejected documents are kept for the record — clients can’t delete a document once it has been reviewed.