MyCase Immigration / Docketwise Integration: 0: Why We Synced · 1: Before/After · 2: OAuth2 · 3: Sync vs Migration · 4: Sync Boundary · 5: Family Graph · 6: Write Patterns · 7: Webhooks · 8: Billing
Once we decided on permanent sync over migration, the first question was: what exactly syncs?
Syncing everything would have been wrong. The two systems have hundreds of entities. Most of them have no reason to cross system boundaries. A USCIS form in Docketwise is purely an immigration concept; it has no use in MyCase. A billing invoice in MyCase is purely a practice management concept; it has no use in Docketwise.
Syncing too little would have broken the use cases that made the integration worth building. If an attorney creates a client in MyCase but the client does not appear in Docketwise, they cannot start an immigration case. If a case exists in Docketwise but not in MyCase, the attorney cannot bill against it.
The boundary had to be right. This post covers how we drew it.
The test
We used one test to decide whether a record type belonged in the sync boundary:
Does a core workflow in each system require reading this record?
If yes for both systems, it belongs in the sync boundary. If yes for only one system, it stays native to that system.
"Core workflow" meant: the workflows attorneys use every day. In MyCase, the core workflow is billing against a client matter. In Docketwise, the core workflow is immigration case preparation.
We applied this test to the candidates:
Client record: Does MyCase's billing workflow require a client? Yes. Does Docketwise's case workflow require a client (as a party to the case)? Yes. Client is in the boundary.
Case record: Does MyCase's billing workflow require a case (matter)? Yes. Does Docketwise's immigration workflow require a case? Yes. Case is in the boundary.
USCIS form: Does MyCase need to read USCIS forms for billing? No. Does Docketwise need them for case preparation? Yes. Stays in Docketwise.
Billing invoice: Does Docketwise need billing invoices for case preparation? No. Does MyCase need them for billing? Yes. Stays in MyCase.
Party role relationships: Does MyCase's billing workflow require knowing whether a client is a petitioner or a beneficiary? No. Does Docketwise's immigration workflow require it? Yes. Stays in Docketwise (but represented as metadata on the Client record that syncs, as covered in Part 5).
Document attachments: Does Docketwise need document attachments from MyCase? No. Does MyCase need immigration-specific attachments from Docketwise? Only for display, not for billing. Stays in Docketwise, surfaced read-only in the MyCase UI.
The test produced a clear result: Client and Case sync. Everything else stays native.
What Client fields sync
Even within Client, not all fields sync. Client in MyCase has billing configuration, communication preferences, portal access settings, and document folders. None of those are relevant to Docketwise.
Client in Docketwise has typed party roles, relationship references to other parties, and immigration-specific identity fields like passport number and country of birth.
The fields that cross the boundary are identity fields both systems use to refer to the same person: name, email, phone. These are 1:1 mappings with no transformation. A first name in MyCase is a first name in Docketwise. An email address is the same string on both sides.
Nullable handling for synced fields: if Docketwise sends a null for a field MyCase has on record, MyCase logs a warning and stores null rather than rejecting. Rejection would leave the local record permanently stale if Docketwise ever sends a field MyCase does not have locally. Validation is Docketwise's responsibility for fields it owns; MyCase stores what it receives.
What Case fields sync
Case in MyCase has billing rate, assigned attorney, deadline tracking, document folders, and invoice history. None of those belong in Docketwise.
Case in Docketwise has visa category, matter type, USCIS form associations, timeline entries, and immigration-specific status values.
The fields that cross the boundary: case name, matter status (active/closed/archived), assigned attorney name, and a foreign key back to the Docketwise case ID stored on the MyCase matter record. The Docketwise case ID on the MyCase matter is how MyCase knows where to send writes that belong to Docketwise.
Immigration-specific case fields stay in Docketwise entirely. MyCase does not store visa category or USCIS form associations. It surfaces them read-only from Docketwise API calls when an attorney opens an immigration case in MyCase.
Why the boundary excludes party role relationships
Docketwise models immigration cases with typed party relationships. A petitioner sponsors a beneficiary. A beneficiary may have derivative beneficiaries (spouse, children). These are not fields on a Client record; they are typed edges in a graph.
This structure is required for immigration case work. USCIS forms reference specific parties by role. The relationship between a petitioner and their beneficiary determines which forms apply. Docketwise needs this graph to do its job.
MyCase does not. A billing workflow does not care whether a client is a petitioner or a beneficiary. The attorney invoices the matter, not the party role.
So: party role relationships stay in Docketwise. But because the sync creates Client records in MyCase for each party, the role and the inter-party FKs are stored as metadata on each MyCase Client. The Case in MyCase links to all participating Clients. Part 5 covers this in detail.
This is the difference between "the sync boundary includes Client" and "the sync boundary includes all Docketwise concepts that attach to Client." The boundary is Client the entity, not the full immigration party graph. The graph metadata rides along because it is needed for correct rendering in the MyCase UI, but it is carried as passive metadata, not as a native MyCase concept.
What the boundary excluded and what that cost
Keeping the boundary narrow added implementation constraints.
Attorneys using MyCase cannot search for clients by visa category from within MyCase native search. That field lives in Docketwise. If they need it for a search, they use the immigration-specific search surface within the MyCase UI, not a MyCase-native query.
Attorneys using Docketwise standalone do not see MyCase billing information. The Docketwise UI has no billing module. An attorney checking outstanding invoices uses MyCase.
These constraints were acceptable because the integration was defined around core workflows, not comprehensive field parity. The goal was to eliminate the manual synchronization overhead of running two systems. It was not to collapse two distinct products into one that did everything both did.
Keeping the boundary at Client and Case let us deliver a working integration in roughly twelve months. Expanding it to cover more entities would have extended that timeline substantially and created more surface area for ordering failures, schema conflicts, and migration complexity.
Next: Part 5. The Family Graph Problem: When Schemas Don't Just Differ in Fields. The sync boundary says Client and Case sync. What it does not explain is why a Docketwise client is not just a MyCase client with extra fields. The structural difference between a typed party graph and a flat Client is the subject of Part 5.
Top comments (0)