Migrate from ServicePower HUB to Salesforce Sales Cloud

ServicePower customers map to Salesforce Accounts. Customer name, phone, email, and billing address transfer directly. Multi-location customers require parent Account setup in Salesforce. ServicePower customer type (Residential, Commercial) maps to Industry pick-list or a custom Customer_Type__c field. We assign the master customer name as the parent Account name and create child Account records for each location, storing the original ServicePower customer identifier in Source_System_ID__c to support upsert deduplication.

ServicePower contact records (scheduling contacts, billing contacts) map to Salesforce Contacts under the Account. Primary contact role preserved as Contact.Salutation and custom Role__c field. Multiple contacts per customer collapse to individual Contact records all linked to the same AccountId. If a contact lacks an email, we generate a placeholder and flag it for your admin to update before go‑live.

ServicePower work orders translate to Salesforce Cases as the central service record. Case.Origin maps from ServicePower job_source (Phone, Web, Portal). Case.Priority maps from ServicePower urgency field. Work order number becomes Case.CaseNumber for reference continuity. Each work order creates one Case in the default record type.

Warranty jobs require a separate Salesforce record type so page layouts, validation rules, and Case status values differ from standard service cases. We create a Warranty_Service record type in Salesforce with a Case_Type__c pick-list set to 'Warranty' for each migrated record. Warranty claim numbers from ServicePower migrate to a custom Warranty_Claim_Number__c field.

Cash-on-demand jobs get their own Salesforce record type with COD-specific status values and payment status fields. COD-specific ServicePower fields (payment_collected, payment_method) map to COD_Amount_Collected__c and Payment_Method__c custom fields on the Case. COD jobs that generated invoices reference the invoice number in Invoice_Number__c.

Employed technicians in ServicePower resolve to Salesforce Users by email match. We query Salesforce Users by the technician's email address — if no match exists, the record is flagged before migration so your admin can invite the user to Salesforce. Unmatched technicians default to a fallback OwnerId (configurable). Active/inactive status from ServicePower maps to User.IsActive.

ServicePower contractors who are not Salesforce users map to Contacts under a dedicated Contractor Account. We create a 'Service Contractors' Account record (or use your designated contractor Account) and link all contractor contacts under it. Contractor skill certifications from ServicePower migrate to custom fields on the Contact record.

ServicePower equipment records (serialized assets, product models) map to Salesforce Assets. Asset.Name from ServicePower serial_number or model_description. Asset.AccountId links to the Salesforce Account representing the customer. Asset.Status reflects current service state. Installed date and warranty expiration dates migrate to InstalledDate and WarrantyExpirationDate fields.

ServicePower parts ordered or used on a work order map to a custom Parts_Used__c junction object (linked to Case and Product) or to Case-level custom fields for simple one-part scenarios. Part number, quantity, unit cost, and distributor source migrate. For high part-count jobs, we recommend the junction object for reporting flexibility. Salesforce PricebookEntries must exist for each part number before migration.

ServicePower work order notes, technician check-ins, and status change records migrate as Salesforce CaseComments. Customer communications (SMS, emails) via ServicePower portal migrate as EmailMessage records linked to the Case. Original timestamps and author information preserved. Attachments on work orders download and re-upload as Salesforce Files.

ServicePower custom properties beyond the standard set — such as customer-specific routing rules, service area tags, or SLA tier flags — require Salesforce custom fields created before migration. We deliver a custom field creation plan specifying API names, data types, and pick-list values so your Salesforce admin pre-provisions the schema. Custom field values migrate directly into the new __c fields.

ServicePower tracks job status transitions with timestamps (Scheduled → Dispatched → In Progress → Completed). Salesforce Case doesn't natively store status history rows. We migrate each transition as a record in a custom Status_History__c object with status_name, transitioned_at (datetime), and transitioned_by fields. This preserves full job lifecycle auditability in Salesforce.

ServicePower payment processing records for COD jobs (amount, method, transaction ID, collected_by) migrate to a custom Payment__c object linked to the Case. For COD jobs that generated formal invoices, we map to Salesforce Order if your org uses Order Management. Transaction timestamps and payment processor references preserved for reconciliation.

ServicePower's service area and territory assignments for technicians map to Salesforce Territory Management or a custom Territory__c object. Technician-to-territory assignments in ServicePower translate to Territory Account assignments or custom Tech_Territory__c junction records. If your org uses Salesforce Maps, we surface territory boundaries for re-configuration in that tool.