Migrate from OctopusPro to Salesforce Sales Cloud

OctopusPro Customers map to Salesforce Contact records with the customer's business name also created as an Account for proper Account-Contact hierarchy. Standard fields — Name, Email, Phone, Address — map directly. Custom fields on the customer profile (e.g., gate codes, pet health history, site-specific notes) map to custom Contact fields that we create in the destination org during schema design. The customer's primary address maps to the Contact MailingAddress and also to the Account BillingAddress. If the customer is a business entity, we create an Account first and link the Contact via AccountId; if the customer is a residential consumer, the Account name mirrors the Contact name per Salesforce's person-account pattern (if enabled) or we use a household Account model.

OctopusPro Bookings are the scheduling anchor — they link a Customer, one or more Field Workers, a Service, a time slot, and a status. We map Bookings to Salesforce Case if the destination is Sales Cloud alone, or to Work Order (Field Service Lightning) if the org includes FSL. The Booking status (Pending, Confirmed, In Progress, Completed, Cancelled) maps to Case Status or Work Order Status with the corresponding Salesforce picklist values. The booked time slot migrates as a combination of the Case or Work Order's CreatedDate (for booking creation time) and a custom field booked_scheduled_datetime__c for the actual appointment time. Bookings that have generated an Invoice link to the Case or Work Order via WhatId.

OctopusPro Jobs capture the actual work performed — they are the operational record linked to a Booking. In Field Service Lightning, we map OctopusPro Jobs to Work Order Line Items (service appointments and line items) or to Tasks attached to the parent Work Order. Job status, description, and resolution notes migrate to Work Order Line Item fields. If the destination is Sales Cloud without FSL, Jobs map to Tasks attached to the parent Case with TaskSubtype indicating the work type. The field worker assignment on the Job maps to the assigned Salesforce User or Contact on the Work Order or Task.

OctopusPro Field Workers include name, role, contact details, pay rates, and GPS tracking preferences. For full-time employees, we map to Salesforce User records by email match, enabling them to log in, own records, and access Field Service Lightning. For contractor or gig-style workers who do not need Salesforce login, we map to Contact records with a Role custom field set to Field Worker. GPS tracking preferences do not have a native Salesforce equivalent — we document the original field worker location tracking settings for the admin to configure in Salesforce Field Service Mobile setup or a third-party geolocation app post-migration.

OctopusPro Invoices include line items, tax, totals, and payment status tied to Bookings. Salesforce Billing (Invoice object) is available only with Salesforce Revenue Cloud and requires additional setup. For most migrations, we map OctopusPro Invoices to a custom Invoice object (custom__c) with line items as a related list. Fields map as follows: Invoice Number to InvoiceNumber, Invoice Date to InvoiceDate, Subtotal to Subtotal, Tax Amount to TaxAmount, Total to Total, and Payment Status to a custom picklist field invoice_status__c (Paid, Unpaid, Partially Paid, Voided). Paid invoices carry the Payment Date; unpaid invoices retain their outstanding balance.

OctopusPro Payment records track amounts, methods, dates, and status against invoices. We map Payments to Salesforce Payment records (Revenue Cloud) or to a custom Payment object linked to the custom Invoice object. Fields map: Payment Amount to Amount, Payment Date to PaymentDate, Payment Method to PaymentMethod (Cash, Card, Bank Transfer, etc.), and Payment Status to Status. Partial payments and refunds migrate as their own records with the original Payment linked via a Parent Payment lookup for audit trails. Voided invoices in OctopusPro are flagged but do not generate payment records in the destination.

OctopusPro Quotes are pre-booking documents with line items, validity dates, and accept/reject status. If the destination org has Salesforce Quotes enabled (Professional tier and above), we map Quotes to the standard Quote object linked to an Opportunity. The Quote validity date migrates to Quote ExpirationDate and the acceptance status maps to a custom field quote_status__c (Pending, Accepted, Rejected, Expired). If Salesforce Quotes are not in scope, Quotes migrate as custom objects attached to the relevant Account or Contact.

OctopusPro Services define what is offered — name, description, pricing rules, duration, and service-area constraints. We map Services to Salesforce Product2 records. Duration maps to a custom field service_duration_minutes__c; pricing rules map to Standard Price Book entries linked to the Product2. Service-area constraints (e.g., zip codes or zones served) map to a custom field service_area__c as a text field; more complex geographic constraints require post-migration geographic assignment configuration in Field Service Lightning.

OctopusPro custom fields on Customer profiles and Bookings (e.g., pet breed for mobile vet, air filter size for HVAC, gate code for field service) have no standard equivalent in Salesforce. We request a full custom field inventory from OctopusPro support as part of the export process, then create matching custom fields on the appropriate Salesforce standard object (Contact, Case, Work Order) during schema design. Field type mapping is done per-field: text fields to Text(255), dates to Date, checkboxes to Checkbox, dropdowns to Picklist. Multi-select in OctopusPro maps to Multi-Select Picklist in Salesforce with a 255-character combined value.

OctopusPro Forms and Checklists capture structured field data — job photos, intake tags, custom questions. Schema varies by service type. We map available form fields to a custom Intake Response object or, for simple key-value pairs, to a rich-text Note attached to the parent Case or Work Order. Photos migrate as ContentDocument records linked via ContentDocumentLink to the parent record. The customer confirms during scoping whether forms need a full custom object or can be handled as structured notes.

OctopusPro records field worker GPS tracks on bookings and jobs. Salesforce Field Service Lightning tracks worker location during active work orders via the Service Appointment relocation feature, but historical GPS traces from OctopusPro have no native equivalent. We map last-known GPS coordinates at the time of booking completion to a custom field last_known_location__c on the Work Order as a Latitude/Longitude geolocation type. Full route history requires a custom GPS tracking object or a post-migration third-party integration (Geotab, Samsara, or similar).

OctopusPro FAQs are linked to specific services and appear in the customer portal and email templates. We extract FAQ content and service associations and migrate them as Salesforce Content Notes linked to the relevant Product2 record, or as Knowledge Articles if the destination org has Salesforce Knowledge enabled. Display configuration (portal placement, email template inclusion) is portal-specific and must be reconfigured in Salesforce Experience Cloud by the customer's admin.

OctopusPro Automations define trigger-action workflows for scheduling notifications, customer reminders, field worker alerts, and status changes. These are platform-specific and cannot be exported as code. We capture the automation rules during scoping — trigger type, conditions, actions, and intended outcome — and deliver a written inventory recommending Salesforce Flow equivalents (record-triggered Flow, scheduled Flow, or Platform Event-driven Flow) for each. The customer's Salesforce admin rebuilds the automations post-migration. This is outside standard migration scope.

The OctopusPro Customer Portal controls online booking display, invoice visibility, FAQ access, and payment links. Portal settings are a configuration layer, not data objects. We do not migrate them. The underlying data — Customers, Bookings, Invoices — that the portal surfaces migrates to Salesforce. The customer's admin rebuilds the customer-facing experience in Salesforce Experience Cloud (Community Cloud) using the migrated data as the foundation.