8.1 Case Management, Databases, Litigation Support & Office Tools

The Paralegal CORE Competency Exam (PCCE) tests law-office management as a systems skill, not as software trivia. You will not be asked to recite a vendor’s current pricing tier. You will be asked what a case management system (CMS) is for, how a database stores a matter, how litigation support differs from everyday practice management, and how access controls protect confidentiality. Brand names such as Clio or PracticePanther are useful classroom examples of a matter-centric CMS. A Relativity-class review platform is litigation support, not a substitute for the firm’s contacts-and-matters database. If a stem names a product, classify the job the product is doing.

What a case management system actually holds

A CMS is the firm’s operational record of who the firm represents, what the matter is, where the documents live, and what still has to be done. At a paralegal level, every competent CMS — cloud or on-premises — is built around the same objects:

• Contacts (also called names or cards): clients, related entities, opposing parties, opposing counsel, insurers, experts, witnesses, judges, clerks, and vendors. A contact is a person or organization, not a lawsuit.
• Matters (files or cases): the engagement itself — Smith v. Jones, the Lopez closing, the Acme asset purchase. One client can have many matters. Each matter has a number, a type, an assigned attorney, an opening date, and, when relevant, a statute of limitations field.
• Documents: correspondence, pleadings, discovery, and work product stored against the matter, not in a random desktop folder.
• Notes: chronological or topical entries (intake notes, call logs, “opposing counsel will produce Friday”).
• Tasks: assigned work with due dates — draft the interrogatories, order the medical records, calendar the Rule 26(f) conference.

Timekeeping, billing, conflict checking, and calendaring are often modules of the same system. They are still separate functions. Opening a matter without a conflict check, or billing from a personal spreadsheet while the CMS sits empty, is how firms lose both money and licenses.

Word-processing integration is the everyday link between the CMS and the document. A caption template pulls the court, the parties, and the matter number from the matter record. A merge field that still says «Client_Name» on a filed pleading is a CMS-to-Word failure, not a “style” issue. Document assembly (engagement letters, form discovery, closing binders) belongs in the template library, with the attorney’s approved form as the source of truth.

Office management tools around the CMS

The blueprint’s office management tools are the intake-to-template layer that keeps the CMS honest:

• Intake questionnaires and conflict worksheets collected before the matter is opened
• Task lists and workflow checklists (new-litigation opening, closing checklist, probate inventory)
• Template libraries for engagement letters, pleadings, discovery, and correspondence
• Document-management conventions: naming, version, and a single official location

A sticky-note culture is not a CMS. A shared drive with no matter numbers is not a CMS. The exam’s correct instinct is: one official record, opened after a conflict check, with documents and tasks attached to that record.

Litigation support is a different job

Litigation support (sometimes called litigation-support systems or review platforms) is the toolset used when the volume of documents — especially electronically stored information (ESI) — exceeds what a correspondence folder can hold. Conceptual examples include Relativity-class review databases, older Concordance-style image bases, and similar platforms. Do not memorize vendors. Memorize the work:

A CMS stores the matter. A litigation-support database reviews the evidence in the matter. Putting 400,000 emails only in the CMS correspondence tab, or trying to run a privilege review only in Word, is the wrong tool. Conversely, using a Relativity-class workspace as the firm’s only contact list is also the wrong tool.

Database concepts at a paralegal level

The PCCE still tests database management: elements, fields, and relational operations. You do not need a computer-science degree. You do need the vocabulary of the file room translated into tables.

• A table is a collection of the same kind of thing — a Contacts table, a Matters table, a Time-Entries table.
• A record (row) is one instance: one contact, one matter, one time entry.
• A field (column, element) is one attribute of that record: last name, matter number, statute of limitations date, hourly rate, privilege tag.
• A primary key uniquely identifies the record (the matter number 2026-0142 is a classic key).
• A query asks the database a question: “all open matters for Attorney Chen with a limitations date in the next 90 days.”
• A filter narrows a table; a sort orders it; a report formats the result.

A relational database stores facts once and relates tables through keys instead of retyping the client’s address into every pleading. The usual law-office pattern is one-to-many: one client, many matters; one matter, many contacts; one matter, many time entries. A join combines records from two tables using a common field. Example: join Contacts to Matters on client_id to list every open file for a corporate family. Join Time Entries to Matters on matter_id to build a prebill.

Paralegal-level relational operations you should be able to name:

1. Select / query — find matching records
2. Join — connect related tables through a key
3. Update — change a field (new address, new party)
4. Append / enter — add a record
5. Validate — required fields, date formats, no blank SOL on a personal-injury file

Data integrity is an ethics problem as well as a tech problem. Two spellings of the same defendant (Jon Smith and John Smyth) will miss a conflict check. A blank party field is how a later-added insurer never hits the database. The cure is a controlled intake: search before you create, use a unique contact card, and add also-known-as and related-entity fields.

Confidentiality and access controls

A CMS that everyone can see is a confidentiality incident waiting for a screenshot. NFPA Rule 1.5 still applies to every field in the database, and EC-1.5(g) reaches remote logins. Tie the technology to the duty:

• Role-based access: a billing clerk does not need the psychiatric independent medical examination; a temp does not need every matter in the firm.
• Matter-level permissions: the default is need-to-know, not “everyone here is family.”
• Ethical walls: when Rule 1.6 requires a screen, information technology removes the person’s credentials from that workspace. A sticky note is not a wall.
• Audit logs: who opened the file, who exported the contact list.
• No personal repositories: do not copy the client table to a USB drive or a consumer cloud folder “so I can work tonight.”
• Least privilege: refuse a request for firm-wide administrator rights unless that is actually the person’s job.

Worked path

A new employment matter arrives. The paralegal searches the CMS contacts and matters for the employee, the employer, related entities, and known insurers before opening a file. No hit. The paralegal creates one client contact, one matter record, and links opposing counsel when identified. Intake notes and the signed engagement letter go into the matter’s document folder. A Word caption template merges the matter fields. Tasks are assigned: medical-record request, Equal Employment Opportunity Commission file request, calendar the limitations date. Six months later the case is in discovery. Forty thousand emails are collected. Those emails are not dumped into the CMS notes tab. They go to a litigation-support review workspace, are Bates-stamped, coded for issues and privilege, and produced with a load file. Access to the psychiatric-records folder is limited to the assigned team. When a lateral from the employer’s former firm joins, IT removes that person from this matter before the first login.