Migrate from ServeManager to Salesforce Sales Cloud

ServeManager Companies represent the law firms and agencies that hire process servers. They map directly to Salesforce Accounts with a one-to-one relationship. Billing address, phone, and primary contact email transfer as standard Account fields. Multi-contact law firms maintain one Account record with multiple Contact records linked beneath it for attorney, paralegal, and ops contacts.

ServeManager stores contacts on Companies — attorneys, paralegals, and ops contacts who request service. They map to Salesforce Contacts with an AccountId lookup back to the mapped Account. Primary flag on ServeManager maps to the first Contact in the Salesforce related list.

ServeManager Jobs hold serve instructions, due date, address, and job type. Salesforce has no native Job object, so we map Jobs to Cases with a custom Job_Number__c field holding the original ServeManager Job ID. Case Origin is set to 'Process Service' to distinguish from other case types.

ServeManager Job statuses (Open, Assigned, Completed, Cancelled) map to Salesforce Case Status pick-list values. Open maps to 'New', Assigned maps to 'In Progress', Completed maps to 'Resolved', and Cancelled maps to 'Closed Lost. You configure the Salesforce pick-list labels before migration to match your existing workflow states.

Each ServeManager Attempt record — with attempt date, time, result (Served, Not Served, Refused), and officer notes — maps to a Salesforce Task under the Case. Task.Subject follows the pattern 'Serve Attempt #N', Task.ActivityDate holds the attempt date, and Task.Status defaults to 'Completed'.

ServeManager captures GPS coordinates on each attempt via its mobile app. Salesforce Tasks have no native geolocation field, so we create two custom decimal fields (Attempt_Latitude__c, Attempt_Longitude__c) on the Task object. Each child Task under the Case receives the GPS coordinates from its parent Attempt, preserving the spatial record for reporting and court-evidence purposes.

ServeManager photos attached to Attempts re-upload as Salesforce Files (ContentDocument). Each File gets a ContentDocumentLink to the child Task so photos appear in the Attempt's related list on the Case. Photos download from ServeManager export, then bulk-upload to Salesforce with the TaskId as the parentId.

ServeManager Invoices have invoice number, amount, status, and line items tied to Jobs. Salesforce has no standard Invoice object below Revenue Cloud. We create a custom Invoice__c object with an AccountId lookup, Job_Number__c reference, Invoice_Number__c, Amount__c, Status__c, and Invoice_Date__c fields.

ServeManager Payments record transaction details against an Invoice with payment date, amount, and Stripe reference. A custom Payment__c object links to the Invoice__c record via a lookup field, storing Payment_Date__c, Amount__c, Stripe_Transaction_ID__c, and Payment_Method__c fields to maintain full payment history within Salesforce.

ServeManager tracks what each server is owed per job — the payable amount, status, and server contact. We create a custom Server_Payable__c object linked to the Job's Case and to the server's Contact record, with fields for Payable_Amount__c, Status__c, and Paid_Date__c.

ServeManager allows custom fields per Job. Each custom field creates a corresponding custom field on the Case object in Salesforce (Custom__c naming convention). We document the full list during discovery, create the fields in your Salesforce org before migration, then map values during the load.

The original ServeManager Job ID is stored as a custom text field on the Case for traceability and delta-run de-duplication. This custom Source_Job_ID__c field allows FlitStack to identify which records were already migrated if a second migration run is needed after go-live.