— Free training · systems & operations
A step-by-step process for turning your practice management exports into one searchable master list — plus the exact mistakes that quietly make a conflict database miss real conflicts, pulled from a live rebuild of one.
— If you're reading this, you already know the problem
Your practice management system has a contact list. It has a matter list. Somewhere in there is every client, every opposing party, every opposing counsel your firm has ever touched — but there is no single place to search "have we seen this name before?" and trust the answer. Most firms skip the check, run it from memory, or dig through three screens and hope they did not miss a tab.
3
exports you likely already have — contacts, matters, companies
1
master list you actually search, not five
0
silent "clear" results once matches require sign-off
— The process
Steps 3 and 4 have to happen before you build anything searchable, or the master list you end up with will actively mislead people.
Step 01
Pull your contact list, matter/case list, and company list from whatever system holds them — Smokeball, Clio, MyCase, PracticePanther, Lawmatics, or a spreadsheet all work the same way here. Raw exports, not a filtered view.
Step 02
Most systems also carry custom fields for opposing party, opposing counsel, petitioner, respondent, judge, GAL, and mediator on the matter record instead of the contact. Read only the primary role field and you will miss people.
Step 03
First-name-only rows, placeholders like N/A or none, and test data get dropped now — before consolidation, not after. Doing it later corrupts the data instead of leaving gaps in it.
Step 04
Phone numbers and long IDs round-tripped through Excel come back as scientific notation (9.54E+09) with the digits unrecoverable. Flag those loudly. A paralegal trusting a corrupted number is worse than one who knows to look it up.
Step 05
Group by normalized full name and merge: every role held, every email and phone, every linked matter, rolled into a single row. This is what turns three scattered exports into one searchable list.
Step 06
Exact whole-name matches in their own group, close misspellings in a separate "possible variant" group. Loose contains-matching buries real hits in noise; no matching misses your own typos.
Step 07
A check that screens the prospective client but skips the opposing party is half a check. Make both names required before a search can run at all.
Step 08
Show role, email, phone, and matter on every hit, and require a named person to review and confirm before anything is marked cleared. That approval, with name and timestamp, becomes part of the record.
Step 09
Add every new lead, party, and case contact as soon as they are identified. Re-export and re-consolidate on a set cadence — monthly is reasonable for most firms.
— What to capture
Full name
The primary search key — the whole reason the list exists.
Role
Client, opposing party, opposing counsel, judge, GAL, witness, family member — every role held, not just the first recorded.
Email / phone
Confirms you matched the right person when two share a name.
Linked case / matter no.
Tells the reviewer which file the connection came from so they can verify it.
Employer / company
Catches conflicts on organizations — opposing counsel's firm, a client's employer.
Source
Saved contact vs. pulled from a matter custom field — useful when a result needs tracing.
Notes
Anything a prior staff member already flagged about this person.
— Where this breaks
Every one of these showed up in a real rebuild and had to be caught and fixed. Check for all four before you trust the result.
Pitfall 01
Many systems reuse contact type for lead stages — Lead, Unassigned, Lost, Unfiled — alongside genuine roles. The true role sits in a different field, or nowhere obvious.
Roughly 60% of one firm's contact records carried a pipeline status instead of an actual role.
Pitfall 02
Two custom fields for the same thing — one from an old intake form, one from current matter entry — and staff only fill in one consistently.
One firm's primary opposing-party field covered 605 matters; a similarly named intake field covered 70. Building from the wrong one missed ~589 known opposing parties.
Pitfall 03
Any record with just a first name merges with every other record sharing that fragment, collapsing unrelated people into one row. Filter before consolidation.
Every unrelated contact named "Jessica" with no last name merged into one row representing 41 people.
Pitfall 04
A naive two-word check treats hyphenated or apostrophe'd first names — Ebony-Joy, T'ronn — as first plus last. Validate on actual whitespace, not a normalized string.
Sample twenty names you know are opposing parties and confirm the database finds each with the right role.
— Search behavior
Show identifying detail on every match so the reviewer can judge whether it is the same person. If nothing is found, say so plainly. If something is found, stop and ask a named person to review and approve before generating anything marked clear. The saved record — who searched what, what was found, who reviewed it, and when — is the point as much as the search itself.
A database that finds everything but lets a match slip through silently is more dangerous than no database at all. The review step is not friction. It is the entire point.
— Run it today
Here are raw exports from my practice management system (contacts, matters, companies). Inventory every column across all files. For each column: what it appears to hold, fill rate, and whether it could contain a party name or role. Flag any column that looks like a pipeline status being used as a role, and any pair of columns that appear to hold the same information. Do not merge or clean anything yet — list findings only.
Using these exports, build a master conflict list. Rules: (1) drop any row with no last name, placeholder values like N/A or none, or obvious test data — do this before grouping; (2) validate first/last name on actual whitespace, never on punctuation; (3) group by normalized full name and merge every role, email, phone, linked matter, employer, and source into a single row; (4) flag any phone or ID that appears as scientific notation as CORRUPTED rather than reporting the number. Output the master list plus a count of rows dropped and why.
Search this master list for two names: [prospective client] and [opposing party]. Both are required — refuse to run if either is missing. Return exact whole-name matches in one group and possible spelling variants in a separate group, never blended. For every match show role, email, phone, linked matter, and source. If anything is found, do not state a conclusion — output a review block requiring a named reviewer and date before the check can be marked cleared. If nothing is found, say so plainly and note the date of the data snapshot.
— Keeping it alive
A conflict database goes stale the day after you build it. Add new leads, parties, and case contacts as part of intake — not as cleanup someone gets to eventually — and re-export and re-consolidate on a set cadence. If a search tool sits on top of the list, refresh its data at the same time and make it state the snapshot date plainly.
Inside the mastermind we build this against your firm's own exports — mapping your fields, running the consolidation, and standing up the search tool with the review-and-approve record attached.
This training describes a general process and is not specific to any one practice management system or jurisdiction's ethics rules. Confirm your own conflict-check obligations with your state bar before relying on any system you build from it.
$1,700 per attorney. Track selection happens in your registrant portal after you enroll, first come, first served.
