Migrate from Fieldproxy to Salesforce Sales Cloud

Fieldproxy Customer maps to Salesforce Account. The customer's primary address becomes Account.BillingAddress. Multi-site customers in Fieldproxy may have multiple Site records — we create one Account with multiple ShippingAddresses or a custom Site__c junction object depending on your Salesforce edition and reporting needs.

Fieldproxy Contact maps to Salesforce Contact with AccountId set to the parent Customer/Account. Primary contact per customer becomes the Account's primary Contact. Additional site-specific contacts are created as additional Contact records under the same Account with site-related custom fields populated.

Fieldproxy Job maps to Salesforce Case when the job represents a service event that should appear in Salesforce's case management model. Case origin is set to 'Field Service'. If your Salesforce edition does not include Service Cloud, Jobs map to a custom Field_Service_Job__c object instead, preserving the same field structure.

Each Fieldproxy Job generates one or more Salesforce Task records representing work items assigned to technicians. Task.Status maps from Job.status, Task.ActivityDate maps from Job.scheduled_date, and Task.OwnerId resolves to the technician's Salesforce User record via email match. If a technician has no corresponding Salesforce User, their Tasks are assigned to a designated fallback Owner during migration. Each Task also links to the parent Case via WhatId so technicians see the full job context in Salesforce.

Fieldproxy Site records with physical addresses map to Account.ShippingAddress (or additional ShippingAddresses if Fieldproxy supports multiple addresses per site). Site-specific notes and access instructions become custom fields on the Account or on a Site__c junction object. We flag sites that share the same customer for de-duplication.

Fieldproxy Asset maps to Salesforce Asset (available in Enterprise and above) or to a custom Asset__c object. Asset.Name maps from Fieldproxy asset name; Asset.AccountId links to the Salesforce Account representing the customer site. Serial numbers, make/model, and installation dates map to Asset.SerialNumber, Asset.Make__c, and Asset.InstallDate respectively.

Fieldproxy job line items map to custom CaseLineItem__c records linked to the Case (Job). If the job generates a Salesforce Opportunity for upsell, line items map to OpportunityLineItem. Each line item's quantity, unit price, tax, and description are preserved. We surface job-to-opportunity mapping rules during discovery so your team decides which service events trigger revenue opportunities.

Fieldproxy technicians resolve to Salesforce Users by email match. Technicians who do not yet have Salesforce user accounts are flagged before migration — your admin either creates Salesforce User records first or assigns their jobs to a fallback owner. Fieldproxy technician skills and certifications map to custom fields on the User record for dispatch planning.

Fieldproxy Quotes map to Salesforce Opportunities with PricebookEntry-linked line items. Quote status (Draft, Sent, Accepted) maps to Opportunity.StageName values your admin configures. Stripe payment links from Fieldproxy Quotes require reconfiguration in Salesforce Payments after migration. We preserve quote history as Opportunity history records.

Fieldproxy Invoices map to Salesforce Orders when your org uses Order Management, or to a custom Invoice__c object when it does not. Invoice line items map to OrderProducts or Invoice_Line_Item__c records. Payment status (Paid, Pending, Overdue) maps to Order.Status or a custom payment status field. Stripe payment records are reference-only in Salesforce — payment reconciliation continues in Stripe.

Fieldproxy custom fields on Jobs require Salesforce custom fields created before migration. We deliver a custom field creation plan listing each Fieldproxy custom property, its data type, and the Salesforce field API name (ending in __c). Custom pick-list fields require value-by-value mapping when source and destination pick-list values differ.

Fieldproxy's GPS check-in timestamps and route data have no native Salesforce equivalent. We migrate check-in records as a custom Location_Event__c object with latitude, longitude, timestamp, and a link to the related Case (Job). This preserves historical location data for audit and SLA compliance but does not enable real-time dispatch — that requires Salesforce Field Service or a third-party FSM app.

Fieldproxy's job checklists and form submissions (e.g., inspection results, parts used) have no Salesforce standard equivalent. We migrate each checklist response as a Checklist_Response__c record linked to the Case (Job), preserving question text, response value, and completion timestamp. Your admin can display these in Salesforce via related lists or a Visualforce/LWC component.