Migrate from FieldEdge to Salesforce Sales Cloud

FieldEdge customers map to Salesforce Accounts. Primary contact within the account becomes a Salesforce Contact with the same name, email, phone, and address fields. FieldEdge company-level billing address maps to the Account's billing address for account-level reference. All contacts are linked to the account via the AccountId field. If multiple FieldEdge contacts exist for one account, we create additional Contact records and ensure each is associated correctly.

FieldEdge work orders have no Salesforce standard equivalent. We create Work_Order__c as a custom object with fields for status (pick-list), technician (Contact lookup), customer (Account lookup), created and modified timestamps (custom datetime), asset (Asset lookup), and original work order number. This preserves the full operational record in Salesforce as a searchable, related list on the Account.

FieldEdge invoices have no Salesforce standard object — Salesforce Revenue Cloud is a separate licensed product. We create Invoice__c to store invoice number, total amount, status (pick-list from FieldEdge values), payment date, and related Account lookup. Line items are preserved as comma-separated detail in a custom text field pending price book configuration.

FieldEdge service agreements map to a custom Agreement__c object in Salesforce with fields for agreement name, start and end dates, coverage type (pick-list), related Account, related Assets (Asset lookups), and pricing term. The full agreement terms are preserved as a text area field. This object does not trigger Salesforce contract management — separate contract records can be created manually post-migration if needed.

FieldEdge technicians and employees map to Salesforce Contacts. A custom Role__c pick-list field on the Contact object distinguishes technician, dispatcher, and office staff. Active FieldEdge technicians who need Salesforce login access require Salesforce User records to be provisioned separately — we flag these for your admin before migration.

FieldEdge assets map to the Salesforce Asset object using the asset name, install date, status (mapped pick-list value-by-value), and related Account lookup. Asset serial numbers and model information map to custom fields on the Asset object. Assets linked to work orders in FieldEdge retain the relationship via the Asset__c lookup on Work_Order__c.

FieldEdge work order line items (parts and labour) can map to OpportunityLineItems if your Salesforce org has a price book configured and an Opportunity is used as the parent. If no Opportunity is relevant, line items are stored as a custom text area on Work_Order__c listing parts, quantities, and rates. We surface the preferred approach during the test migration review.

FieldEdge records work order created date, modified date, and status-change timestamps. Salesforce's native CreatedDate and LastModifiedDate reflect migration time, not the original FieldEdge record history. We preserve original dates as custom datetime fields on Work_Order__c for reporting continuity. This ensures historical trend analysis remains accurate after the migration.

FieldEdge file attachments on work orders, invoices, and customers re-upload as Salesforce Files. Files are linked to their parent record (Work_Order__c, Invoice__c, or Account) via ContentDocumentLink. File size limits from Salesforce apply — 25MB per file by default. Photos attached to work orders by technicians are preserved as they are.

FieldEdge links products and parts to work orders as line items. In Salesforce, products require a PricebookEntry and Opportunity context. We create a custom junction object (Work_Order_Product__c) with lookups to Work_Order__c and Asset, plus product name and quantity fields, when no Opportunity is in scope. If your org already uses Opportunities for product pricing, we can map the junction records accordingly during the test migration.

FieldEdge dispatch board notes and technician commentary on work orders migrate as Salesforce Notes attached to Work_Order__c. Original timestamps and the creating technician (Contact) are preserved in the Note's created-by and created-date fields.

FieldEdge workflow rules, dispatch triggers, and service-agreement automation do not have Salesforce equivalents. They must be rebuilt in Salesforce Flow or Apex triggers. We export FieldEdge workflow definitions as a reference document your Salesforce admin can use to reconstruct the logic in Flow Builder. We recommend documenting each workflow's trigger conditions and actions to simplify the translation into Flow Builder elements.

FieldEdge operational reports and dispatch board analytics have no Salesforce equivalent. Report definitions do not migrate. The underlying data — work orders, invoices, and technician activity — is preserved in Salesforce custom objects, so reports can be rebuilt using Salesforce standard reports or Analytics Cloud against the migrated data.

Any FieldEdge custom objects or custom fields on standard objects require a custom field on the corresponding Salesforce object. We audit your FieldEdge schema during discovery, map each custom field by data type and pick-list values, and create the Salesforce custom fields before data loads. Complex pick-list value mappings are validated in the test migration phase.

FieldEdge's native QuickBooks integration syncs invoices and payments bidirectionally. Salesforce requires a separate integration (native Salesforce connector, Bodi, or a middleware) to sync accounting data. Invoice records migrate into Salesforce Invoice__c, but the live sync with your accounting software requires a post-migration integration project.

FieldEdge owner IDs on work orders and invoices resolve to Salesforce Contacts by email match. Unmatched owners are flagged before migration. Active technicians who need Salesforce access must be provisioned as Salesforce Users by your admin — we provide a User-provisioning checklist alongside the migration plan.