How CMIForge Works

Big Picture

CMIForge is a configurable legal intake and conflicts platform. The core idea is simple: build intake forms, collect submissions, route those submissions through workflow, run conflict checks, and convert approved submissions into client and matter records.

1. Create or edit a form.
2. Attach a workflow to the published form version.
3. Users submit the form.
4. Workflow tasks route to users or teams.
5. Conflicts can be run from a submission or matter context.
6. Approved submissions can be converted into client and matter records.

Forms

Forms define the intake questions users answer. CMIForge stores form designs as versioned schemas so historical submissions still render against the exact form version that was used at the time.

• Create Form publishes the first version.
• Edit Form publishes a new version instead of changing older submissions.
• Blank designer rows are ignored.
• Select, radio-style, and checkbox-style fields use static options for now.
• A form version can be attached to a workflow definition.

Submissions

Submissions are completed intake forms. Each submission receives a stable number and can be reviewed, routed, converted, and linked back to operational records.

• Status values include Submitted, In Review, Approved, Returned, and Converted.
• My Submissions shows the current user's work.
• All Submissions is permission-gated.
• Conversion is locked until a submission is approved.
• Converted submissions link to the created client and matter.

Workflows

Workflows define approval steps. A workflow can be scoped to a form or used as a fallback, and a published form version can point to a workflow definition.

• Workflow steps are ordered by step number.
• Steps can be assigned to a user, a team, or both.
• Workflow queues include personal, team, and all-open views based on permissions.
• Outcomes can advance, complete, or return a workflow.
• Answer-based routing can run steps only when a submitted field matches a condition.

Outcome format: use Label|Action|Status|Next step, separated by semicolons. Example: Approve|Advance|In Review; Return|Return|Returned.

Entities

Entities are operational records used by the platform after intake is approved or data is imported.

• Clients have client numbers, contact details, status, and related matters.
• Matters have matter numbers, client links, status, practice area, responsible user, and related parties.
• Parties support conflicts searching through names, aliases, relationships, and matter roles.
• Users are application data users with system IDs, name parts, email, title, activity status, teams, and roles.

Conflicts

Conflict searches compare entered search terms against the party index. The search engine normalizes names, checks aliases, scores fuzzy matches, and expands strong matches through known party relationships.

• Searches can be linked to a submission or a matter.
• Results show score, risk, matched party, matter/client context, explanation, and AI assist assessment.
• Reviewer decisions are currently recorded at the overall search level.
• Previous conflict searches are retained as history, but search matching currently runs against parties, aliases, relationships, clients, matters, and matter-party roles rather than prior search result text.

Current review behavior: use the search-level reviewer decision and notes to document overall clearance. Per-result clearance decisions are a planned next slice.

Imports

The Import Center loads CSV files for clients, matters, and parties. Each import card includes a downloadable template, validation mode, and import mode.

• Validate CSV checks the file and stores row-level messages without creating or updating records.
• Import CSV runs the same checks and writes the accepted rows.
• Clients upsert by ClientNumber.
• Matters upsert by MatterNumber and require an existing ClientNumber.
• Parties link to matters by MatterNumber and reuse existing parties by normalized name.

Security

CMIForge has an internal role and permission model. Authentication is optional during local development, but permissions still control what the current user can see and do.

• Users can have direct roles.
• Teams can have roles.
• Users inherit permissions from their teams.
• Navigation and server-side page handlers both enforce permissions.
• Optional Microsoft Entra login can map authenticated people to rows in the Users table.

Plans

Plans are currently hardcoded product gates, not billing. They help test the product shape before payment infrastructure exists.

• Free: limited users and matters, basic forms, basic conflicts.
• Standard: more users, workflow, email notifications, audit trail, and time recording.
• Professional: unlimited users, advanced workflow, reporting, Entra/SSO, and future advanced features.

The development build is currently hardcoded to Professional so development work is not blocked by feature gates.

Current Limits And Next Slices

• Conflict result clearance is currently search-level only. Per-result clearance needs result-level status, notes, reviewer, and timestamp fields.
• Conflict searches do not yet search the text of previous searches or previous result notes.
• Submission attachments now support small PDF, Word, Excel, and hyperlink records. Richer attachment workflows are still a future slice.
• Workflow versioning is not fully separated from workflow editing yet, so careful admin control matters.
• The current UI is functional and work-focused; richer designer screens are still a future slice.