Migrate from The Plaintiff to Salesforce Sales Cloud

Each The Plaintiff party becomes a Salesforce Contact. The Plaintiff stores the party role (Plaintiff, Defendant, Witness) as a structured field; Salesforce has no native equivalent, so we create a custom Party_Role__c pick-list field on Contact to preserve the role designation. Parties without a primary company association require an 'Unassigned Account' placeholder so the AccountId lookup resolves correctly on load.

Direct 1:1 map to Salesforce's standard Case object. Case type, court name, jurisdiction, opposing counsel, and practice area become custom fields on Case (e.g., Court_Name__c, Practice_Area__c, Opposing_Counsel__c) since Salesforce has no native court or jurisdiction object. The primary contact party links via the Case's primary ContactId. Original case_number from The Plaintiff is stored as Case_Number__c, not in Salesforce's auto-numbered CaseNumber field.

The Plaintiff supports N:N party-case associations natively — one case can have multiple parties each with a distinct role. Salesforce's standard Contact Roles on Cases supports only one primary contact per role type. We create a custom junction object, Party_Case_Junction__c, with lookup fields to Contact and Case plus a Role__c pick-list matching The Plaintiff's role values. This preserves the full party hierarchy for complex multi-party litigation.

All The Plaintiff activities — filings, depositions, court dates, client calls — migrate as Salesforce Tasks (for discrete actions) or Events (for time-blocked court appearances). The activity type (Filing, Deposition, Call, etc.) is preserved in a custom Activity_Type__c field since Salesforce Tasks have a standard Type pick-list that may not cover legal-specific activity categories without custom value sets.

Opposing counsel in The Plaintiff is typically stored as a free-text party name, not a structured contact. We attempt to match the name against existing Salesforce Contacts by email domain or name. Where no match exists, we create a new Contact record with Party_Role__c set to 'Opposing Counsel' and link it via the Party_Case_Junction__c junction object to the associated case.

Salesforce has no native court or jurisdiction object. Court name and jurisdiction from The Plaintiff migrate as custom text fields on the Case object — Court_Name__c and Jurisdiction__c — so historical court information is searchable and reportable in Salesforce without requiring a separate court lookup object.

Owner records in The Plaintiff are resolved by email address against Salesforce Users. Unmatched owners are flagged before migration begins — teams either provision Salesforce user accounts or assign records to a designated fallback user. No case or contact lands in Salesforce without a resolved OwnerId.

Documents attached to The Plaintiff cases — pleadings, correspondence, exhibits — are downloaded and re-uploaded as Salesforce Files linked to the Case record. File size limits follow Salesforce's 25MB per file default; files exceeding this threshold are flagged for manual chunking or alternative storage.

Any custom properties defined in The Plaintiff migrate as Salesforce custom fields on the equivalent object. Data types are preserved (text stays text, pick-list stays pick-list, date stays date). Pick-list values in The Plaintiff require explicit value-mapping against Salesforce's allowed values for the target field.

Salesforce sets CreatedDate and LastModifiedDate at the time of insertion — the original The Plaintiff timestamps are lost by default. We preserve the original create date and last-modified date as Case_Created_In_Source__c and Case_Last_Modified_In_Source__c custom datetime fields so historical aging and audit reporting remain accurate in Salesforce.