Migrate from FieldFX to Salesforce Sales Cloud

FieldFX Ticket maps directly to Salesforce Case. The FX__Ticket__c record number becomes the Case CaseNumber. Status values (New, In Progress, Resolved) map to Salesforce Case Status pick-list via value_mapping. Original FX status-entered timestamps are preserved as custom datetime fields on the Case.

FX WorkOrder maps to Salesforce Field Service Management's ServiceAppointment object if FSM is enabled. Without FSM, WorkOrder data maps to a custom Work_Order__c object. Scheduled start/end times from FX map to ScheduledStart and ScheduledEnd on ServiceAppointment; FX__WorkOrder__c.Status maps to ServiceAppointment Status.

Job__c is a core FieldFX object with no direct Salesforce standard equivalent. Migrates as a custom object Job__c in the destination org. Parent Account lookup maps to the standard AccountId field. Job type and priority fields become custom pick-list fields on Job__c.

FX CPQ quotes do not map to Salesforce CPQ directly — CPQ has its own product, pricing, and quote-object architecture. FX Quote__c line items map to OpportunityLineItems on the target Opportunity. Quote headers (terms, expiration, discount %) require manual rebuild in Salesforce CPQ or mapping to Opportunity fields.

FieldFX Timecards map to Salesforce standard TimeSheet and TimeSheetEntry objects. Technician hours, work date, and billable/non-billable flags transfer directly. Timecard entries link to the Job__c or ServiceAppointment via lookup fields. The TimeSheet parent record is created per technician per work week, with individual TimeSheetEntry records for each shift or task logged during that period.

Service activities logged against an FX Ticket (technician call notes, signature captures, parts consumed) migrate as Salesforce Tasks linked to the Case. Signature images stored as FX file attachments re-upload to Salesforce Files and link to the Case record. Each activity type retains its original timestamp and technician attribution for complete service history continuity in Salesforce.

Customer Self-Service submissions (approval logs, job status views) have no Salesforce equivalent as a portal object. Submission history migrates as Case comments or a custom portal log object. Customer accounts and contacts use standard Account and Contact objects. The portal login history and approval chain records are preserved as related Case history entries or custom log records for audit trail continuity.

DataGuide form submissions (inspection checklists, safety forms tied to Job or Ticket) have no standard Salesforce equivalent. Form responses migrate as a custom Form_Response__c object with custom fields matching the form schema. Form versions require manual re-creation in Salesforce. The migrated response data includes all field values, completion timestamps, and the technician or customer who submitted each form.

FieldFX technicians are stored in a custom Technician__c object. Migration resolves each technician by email match to a Salesforce User record and creates a corresponding ServiceResource record for field service capacity planning. Unmatched technicians are flagged before migration. If Salesforce Field Service Management is enabled, ServiceResource records enable skill-based assignment and availability tracking for each technician.

Equipment linked to Jobs or Tickets via FX__Asset_Link__c maps to Salesforce Asset linked to the Account and/or Product2. Asset serial numbers, install dates, and warranty information transfer directly. The Asset object in Salesforce maintains the full equipment history including maintenance records and customer assignments, providing a complete asset registry post-migration.

FX Invoicing module produces invoices and payment records. Salesforce Sales Cloud has no native invoicing — these become custom Invoice__c and Payment__c objects, or map to Salesforce Orders if Order Management is enabled. The financial data is preserved for reference but billing workflows require rebuild.

Status Workflows define the sequence of statuses a Ticket or Work Order can follow. This is an automation configuration, not a data record. Workflow definitions do not migrate — FlitStack exports the workflow schemas as JSON reference documents for your Salesforce admin to rebuild in Flow.