Migrate from Actionstep to Salesforce Sales Cloud

Actionstep Matters split by intent: client service matters (billable work) route to Salesforce Case; business development or sales-cycle matters route to Opportunity. We preserve Matter ID as Source_Matter_ID__c for traceability. Matter status (Active, Pending, Closed) maps to Case.Status or Opportunity.StageName based on split destination.

Client Participants map to Salesforce Contacts linked to an Account. The Account is either pre-existing in Salesforce or created from the Matter's client name during migration. Participant email, phone, and address fields map directly. The AccountId lookup on Contact is set from the parent Matter's client Account.

Non-client Participants have no native Salesforce Contact Role equivalent. We migrate them as Contacts with a custom pick-list field Participant_Role__c storing the Actionstep contact_type value (Opposing Counsel, Witness, Expert, Vendor). The field is created in Salesforce before migration. If your firm needs granular role tracking, a custom Participant_Role junction object is an alternative.

Actionstep Data Collections are matter-type-scoped custom fields — a Litigation matter has different fields than a Real Estate transaction. We map each Data Collection field to a Salesforce custom field on Case (for matter-specific data) or Account (for client-level data). Pick-list values are migrated value-by-value. The custom fields must be pre-created in Salesforce; we deliver a schema setup plan specifying field labels, API names, types, and pick-list values per matter type.

Actionstep Steps (Intake, Discovery, Review, etc.) represent matter progression with conditional branching. Salesforce has no step-based workflow equivalent — we migrate current Step value as a custom pick-list field Case.Current_Step__c. Step history (all steps entered) is stored as a custom text area field Case.Step_History__c in JSON format for audit purposes. Automation based on step progression must be rebuilt in Salesforce Flow.

Actionstep documents are downloaded from the API, preserving original file names and content. They are uploaded to Salesforce as ContentVersion records, then linked to the target Case via ContentDocumentLink with LinkedEntityId = Case ID. File size limits (25MB default per Salesforce) apply; files exceeding this are chunked. Inline document tags from Actionstep are stored as ContentVersion.Description for reference.

Actionstep time entries (billable hours logged against matters) have no native Salesforce equivalent for billing. We migrate them as Salesforce Tasks with Subject = time entry description, ActivityDate = work date, and custom fields Duration_Minutes__c and Billable__c. For firms using Salesforce Finance CRM or a billing integration, time entries are surfaced as a migration reference dataset for rebuild in the billing system.

Actionstep trust accounting (IOLTA pools, client ledger entries, tri-party trust) has no Salesforce Sales Cloud equivalent. We create a custom object Trust_Transaction__c with fields for Transaction_Type__c, Amount__c, Date__c, IOLTA_Pool__c, and a lookup to Contact. Trust balance reconciliation is out of scope; firms needing trust accounting in Salesforce should evaluate legal-specific add-ons like LexisNexis SmartDraw or third-party integrations.

Actionstep invoices are migrated as a custom object Invoice__c linked to Case and Contact. Fields include Invoice_Number__c, Amount__c, Status__c, Date__c, and Description__c. Tax calculations, payment terms, and aging are not migrated — those are billing-system logic that must be rebuilt in your chosen billing platform.

Actionstep calendar events (meetings, hearings, deadlines) map to Salesforce Events with original start/end times preserved. The WhatId on Event links to the target Case. OwnerId is resolved by email match to Salesforce users. Recurring events are expanded to individual Salesforce Events with a custom Recurrence_Group_ID__c field linking them.

Actionstep supports custom objects via FilePro integration and data collections with custom relationships. These map 1:1 to Salesforce custom objects. If the source uses N:N relationships (e.g., a Participant linked to multiple Matters), Salesforce junction objects are created with two lookup fields. We document every custom object and relationship in the migration plan.

Actionstep notes (text entries on matters) migrate as Salesforce Notes (not the legacy Note object) with Body, Title, ParentId linking to the target Case, and OwnerId resolved by email match. Rich-text formatting is preserved as HTML in the Note.Body field.