Migrate from FieldAware by GPS Insight to Salesforce Sales Cloud

FieldAware Customers map to Salesforce Accounts. The primary company name becomes Account.Name, the website maps to Account.Website, and the industry field maps to Account.Industry with explicit pick‑list value mapping. The primary billing contact is created as a separate Contact linked to the Account via AccountId, preserving the contact’s email, phone, and title. The original FieldAware customer ID is stored as Source_System_ID__c for traceability.

FieldAware Jobs are the core FSM record and map to Salesforce Cases as the service-work equivalent. Job status (Open, Scheduled, In Progress, Completed, Cancelled) maps to Case Status via explicit value mapping. Job type (Repair, Maintenance, Installation, Inspection) maps to Case Type. Original job number preserved as Case.CaseNumber or custom field.

FieldAware Locations represent service sites tied to a Customer. In Salesforce, Locations become Account address records or a custom Location__c junction object — chosen during schema design based on your reporting requirements. If you use Salesforce Field Service, we map Locations to the native Location object with full address and contact details.

FieldAware Contacts migrate directly to Salesforce Contacts. Email is the unique identifier for deduplication and link resolution. Each Contact receives an AccountId lookup to the parent Account created from the FieldAware Customer. Phone, job title, and address fields map directly to Salesforce Contact equivalents.

FieldAware Assets migrate to Salesforce Assets. SerialNumber, InstallDate, Status, and description map directly, with Status values aligned via pick‑list mapping. Each Asset receives an AccountId lookup to the parent Account from the FieldAware Customer. Custom properties declared in FieldAware — such as warranty type, service interval, or location reference — migrate as custom fields on the Salesforce Asset object. The original asset ID is stored as Source_System_ID__c for traceability.

Salesforce Sales Cloud has no native invoice object in most editions. We create a custom Invoice__c object with fields for invoice number, date, due date, total amount, status, and line items. The FieldAware invoice ID is preserved as Source_System_ID__c for traceability. Salesforce Revenue Cloud handles native billing for organizations that need it post-migration.

FieldAware Quotes map to Salesforce Opportunities as the sales-work equivalent, with a custom Quote__c field for detailed line-item information. Quote number, status, description, expiration date, and total amount all migrate. Line items become custom Quote_Line_Item__c records or Opportunity Products depending on your Salesforce configuration.

FieldAware Tasks migrate directly to Salesforce Tasks. Subject, Description, and DueDate map to their Salesforce equivalents, with DueDate stored as ActivityDate. Task Status is aligned via pick‑list mapping to the Salesforce Task Status values. The task owner is resolved by matching the FieldAware user email to a Salesforce User record; unmatched owners are flagged for fallback assignment. The original FieldAware task ID is preserved as Source_System_ID__c to support delta‑run deduplication.

FieldAware Items (parts, materials, services) migrate to Salesforce Products. Item name, part number, description, and unit price all map directly to Product2.Name, ProductCode, Description, and UnitPrice. Category or item type maps to Product2.Family. Items are inserted into the Standard Pricebook via PricebookEntry records.

FieldAware custom field declarations — text, number, checkbox, dropdown, date, time — map to custom fields on their Salesforce object equivalents. Dropdown pick‑list values must be created in Salesforce before migration so field validation passes. We create the Salesforce custom field declarations during the schema setup phase; you choose which custom fields to migrate versus archive.

FieldAware users and technicians are resolved by email match against Salesforce User records. Unmatched users are flagged before migration — your team either provisions Salesforce User accounts first or assigns their records to a fallback owner. Technician scheduling status from FieldAware migrates as a custom field on the Case.

FieldAware preserves job status and type change logs as part of the job record. Salesforce Case History tracking has field-count limitations, so we migrate this as custom datetime and text fields on the Case object — Status_Changed_To__c, Type_Changed_To__c — to preserve the full audit trail for service-history reporting.

FieldAware job numbers are preserved as Salesforce Case CaseNumber for cross-system traceability. If your Salesforce org uses auto-number CaseNumber format, we use a custom Job_Number__c text field instead. This ensures service tickets can be cross-referenced without requiring a custom join.

FieldAware supports nested location hierarchies where a customer has parent and child service sites. In Salesforce, nested locations require either Account hierarchy using Parent AccountId or a custom Location_Junction__c object. We choose based on your reporting structure during the schema design phase.