CRM migration
Field-level mapping, validation, and rollback between Assembly Trialworks and Salesforce Sales Cloud. We move data and schema; workflows are rebuilt natively in Salesforce Sales Cloud.
Assembly Trialworks
Source
Salesforce Sales Cloud
Destination
Compatibility
12 of 12
objects map 1:1 between Assembly Trialworks and Salesforce Sales Cloud.
Complexity
BStandard
Timeline
5–10 business days
Overview
Assembly Trialworks stores data as plaintiff law firm cases: clients as parties, injuries, medical records, statutes of limitations, and case documents in a file-tab structure. Salesforce Sales Cloud has no native legal case object in its standard Sales Cloud edition — cases live in Service Cloud or as custom objects. The migration carries everything Trialworks stores natively (client records, case details, medical record references, statute dates, document attachments, custom fields) into Salesforce's Account-Contact-Case-Opportunity model. The harder problems are mapping Trialworks party types to Salesforce Contacts, preserving the multi-tab case file structure across a custom Case object, handling statute-of-limitations date logic, and re-uploading document attachments to Salesforce Files or a linked DMS. We sequence the migration so foreign keys resolve correctly: Accounts first, then Contacts, then Cases with parent Account and Contact lookups, then custom objects for medical records and injuries. A delta-pickup window captures any Trialworks records modified during cutover. We use Salesforce Bulk API 2.0 for efficient record loading with batch-level error handling. All automations, workflows, and templates in Trialworks do not migrate — we export those definitions as rebuild references for your Salesforce admin.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Assembly Trialworks object lands in Salesforce Sales Cloud, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Assembly Trialworks
Party (Client/Plaintiff)
Salesforce Sales Cloud
Contact
1:1Trialworks party records with role type 'Plaintiff' or 'Client' map directly to Salesforce Contacts. Each party record's name, address, phone, and email fields translate to Contact standard fields. The Contact's AccountId lookup points to the primary defendant Account or a default 'Matter' Account structure your firm defines before migration.
Assembly Trialworks
Party (Defendant / Medical Provider / Witness)
Salesforce Sales Cloud
Contact
1:1Non-client party records (Defendant, Medical Provider, Insurance Adjuster, Witness) map to Salesforce Contacts with a custom Party_Role__c picklist field to preserve the Trialworks role type designation. Multiple contacts can share the same Case parent. The original role value is captured in the custom field for reporting and rebuild reference.
Assembly Trialworks
Case / Matter
Salesforce Sales Cloud
Case (custom object) or Opportunity
1:1Trialworks case files map to a Salesforce custom Matter__c object or to the standard Case object if your org includes Service Cloud. We recommend a custom object because it supports the multi-tab structure Trialworks uses. Each tab (Parties, Medical Records, Injuries, Statutes) becomes a related list or a child custom object with a lookup to Matter__c.
Assembly Trialworks
Medical Record Reference
Salesforce Sales Cloud
Custom: Medical_Record__c
1:1Trialworks medical record entries (provider name, date of service, record type, chart reference) have no Salesforce standard equivalent. We create a Medical_Record__c custom object with a lookup to the Matter__c parent and map each field individually. If records include attached files, those are re-uploaded to Salesforce Files and linked via ContentDocumentLink.
Assembly Trialworks
Injury / Damages Record
Salesforce Sales Cloud
Custom: Injury__c
1:1Injury descriptions, body parts affected, and damage categories from Trialworks tab fields map to a custom Injury__c object linked to Matter__c. Each injury gets its own record so your Salesforce reports can filter by injury type or body part. Injury severity and ICD code references map to custom picklist or text fields.
Assembly Trialworks
Statute of Limitations Date
Salesforce Sales Cloud
Custom: Statute_of_Limitations__c (field on Matter__c)
1:1Trialworks statute-of-limitations dates map to a Statute_of_Limitations__c date field on the Matter__c object. A companion Statute_Alert_Date__c field (calculated as 90 or 180 days before the deadline) enables Salesforce Flow alerts. Firms can extend this with a Formula field that displays days remaining as a traffic-light indicator.
Assembly Trialworks
Case Document / Attachment
Salesforce Sales Cloud
Salesforce Files (ContentDocument / ContentVersion)
1:1Trialworks file attachments are downloaded from the case file tabs (PLEADINGS, DISCOVERY, MEDICAL, CORRESPONDENCE) and re-uploaded as Salesforce Files. Each file is linked to the Matter__c record via ContentDocumentLink. Original file names, categories, and upload dates are preserved in Salesforce File metadata. Large document sets may require chunked upload batches.
Assembly Trialworks
Insurance / Coverage Information
Salesforce Sales Cloud
Custom: Insurance_Coverage__c
1:1Insurance carrier, policy number, coverage limits, and deductible information from Trialworks maps to a custom Insurance_Coverage__c object linked to Matter__c. Policy type (auto, GL, workers' comp) maps via value_mapping to a custom picklist. Coverage amounts map to currency fields with the original currency preserved.
Assembly Trialworks
Firm User / Staff
Salesforce Sales Cloud
User
1:1Trialworks user accounts are matched to Salesforce Users by email address. Active Trialworks users with a confirmed Salesforce User match get their cases assigned to their Salesforce UserId as OwnerId. Unmatched users are flagged before migration — your admin either creates Salesforce User accounts first or assigns those records to a fallback owner.
Assembly Trialworks
Calendar / Deadline Entry
Salesforce Sales Cloud
Event / Task
1:1Trialworks calendar entries and court deadline reminders map to Salesforce Events (for scheduled hearings or depositions) or Tasks (for to-do items). The original event date, time, and description map to Event.StartDateTime and Subject fields. Court deadlines that require all-day reminders map to Salesforce Tasks with IsAllDayEvent=true and a custom Due_Date__c datetime field.
Assembly Trialworks
Custom Field (per-firm)
Salesforce Sales Cloud
Custom field on destination object (__c)
1:1Every Trialworks custom field maps to a Salesforce custom field on the appropriate destination object. Field type mapping follows standard conventions: text fields to Text(255), long text to Long Text Area, dates to Date, pick-lists to picklist with values preserved. Salesforce __c suffix is applied to all custom field API names. Fields are created in the target org before the migration run.
Assembly Trialworks
Billing / Fee Arrangement
Salesforce Sales Cloud
Custom: Fee_Arrangement__c
1:1Contingency fee percentages, hourly rates, flat fees, and retainer amounts from Trialworks map to a Fee_Arrangement__c custom object or fields on Matter__c. Fee type maps via value_mapping to a structured picklist (Contingency, Hourly, Flat Fee, Hybrid). Outstanding balance tracking is not native to Salesforce and requires a custom field or integration with a billing tool.
| Assembly Trialworks | Salesforce Sales Cloud | Compatibility | |
|---|---|---|---|
| Party (Client/Plaintiff) | Contact1:1 | Fully supported | |
| Party (Defendant / Medical Provider / Witness) | Contact1:1 | Fully supported | |
| Case / Matter | Case (custom object) or Opportunity1:1 | Fully supported | |
| Medical Record Reference | Custom: Medical_Record__c1:1 | Fully supported | |
| Injury / Damages Record | Custom: Injury__c1:1 | Fully supported | |
| Statute of Limitations Date | Custom: Statute_of_Limitations__c (field on Matter__c)1:1 | Fully supported | |
| Case Document / Attachment | Salesforce Files (ContentDocument / ContentVersion)1:1 | Fully supported | |
| Insurance / Coverage Information | Custom: Insurance_Coverage__c1:1 | Fully supported | |
| Firm User / Staff | User1:1 | Fully supported | |
| Calendar / Deadline Entry | Event / Task1:1 | Fully supported | |
| Custom Field (per-firm) | Custom field on destination object (__c)1:1 | Fully supported | |
| Billing / Fee Arrangement | Custom: Fee_Arrangement__c1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Assembly Trialworks gotchas
No public API means migration requires direct SQL database access
Assembly has discontinued custom dashboard creation and modification
FileIT document import requires a parallel folder-to-case mapping step
Custom fields are firm-specific and must be discovered before mapping
Firms being pushed toward cloud-only Neos despite needing on-premise
Salesforce Sales Cloud gotchas
Workflow Rules and Process Builder are retired
Bulk API batch quota exhaustion during large imports
Storage overage billing is non-obvious
Account-Contact many-to-many relationship mapping
Territory and team member import ordering dependencies
Pair-specific challenges
Migration approach
Stand up Salesforce schema first
Before data moves, we create the custom objects (Matter__c, Medical_Record__c, Injury__c, Insurance_Coverage__c), custom fields (__c suffix), and custom picklists your migration needs. We deliver a schema setup plan based on your Trialworks configuration — the number of custom fields per object, the number of case tabs, and the document categories in use. Your Salesforce admin reviews and creates the schema in your sandbox before we run validation. This step runs in parallel with data extraction planning from Trialworks.
Extract Trialworks data and resolve party contacts
We extract all records from Trialworks via file export or API access: parties, cases, medical records, injuries, insurance coverage, calendar entries, and document file lists. Parties are deduplicated across cases using email matching and a firm-defined primary-contact rule. Document files are downloaded in structured batches preserving the case-folder hierarchy. Unmatched attorney users (for OwnerId resolution) are flagged so your admin can create Salesforce User accounts or assign a fallback owner before migration.
Run sample migration with field-level diff
A representative slice migrates first — typically 100–500 records spanning cases, parties, medical records, and document attachments. We generate a field-level diff between the Trialworks export and the Salesforce target so you can verify that statute-of-limitations dates landed correctly, party roles mapped to the right picklist values, and document categories preserved the Trialworks folder structure. This step identifies any missing picklist values, required field gaps, or mapping errors before the full run commits.
Cut over with delta-pickup for in-flight records
Full migration runs against Salesforce using Bulk API 2.0 for efficient batch loading. A delta-pickup window (typically 24–48 hours) captures any Trialworks records created or modified during the cutover — for example, new parties added by staff who were working in Trialworks while the migration ran. Audit log captures every operation. One-click rollback is available if reconciliation fails or record counts do not match expectations. After rollback confirmation, the delta records are merged in a follow-on run.
Deliver migration handoff package
After successful cutover, we deliver a migration handoff package containing: the full field mapping spreadsheet, Salesforce Flow definitions for statute-of-limitations alerts and case status change reminders, a custom report type definition for cross-object case reporting, a Trialworks automation export (PDF) for your admin to rebuild in Flow, and a post-migration data quality report showing record counts, duplicate counts, and any records that landed with warnings. We schedule a 30-day post-migration support window for any data corrections.
Platform deep dives
Assembly Trialworks
Source
Strengths
Weaknesses
Salesforce Sales Cloud
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Assembly Trialworks and Salesforce Sales Cloud.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Assembly Trialworks: Not applicable—no public API.
Data volume sensitivity
Assembly Trialworks doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Assembly Trialworks to Salesforce Sales Cloud migration scoping. Not seeing yours? Book a call.
Walk through your Assembly Trialworks to Salesforce Sales Cloud migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Assembly Trialworks
Other ways to arrive at Salesforce Sales Cloud
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.