Migrate from Forms On Fire to Salesforce Sales Cloud

Forms On Fire forms have no direct Salesforce equivalent. Each form becomes either a Salesforce custom object (for structured domain data like inspections or audits) or maps to a standard CRM object (Account, Lead, Case) when form submissions represent customer or prospect interactions. Your team decides the target object per form before migration runs.

Individual form submissions map row-by-row to Salesforce records. If the target object is a custom object (Inspection__c), each submission creates one Inspection__c record. The submission's original creation timestamp maps to a custom Created_In_Source__c datetime field since Salesforce's CreatedDate reflects migration time.

Forms On Fire text fields map to Salesforce Text fields. Short text (under 255 chars) maps to Text(255); longer responses map to Text Area Long (textarea). Character limits are enforced during migration — text exceeding Salesforce field length is truncated and flagged in the migration report.

Forms On Fire number fields map to Salesforce Number fields with appropriate precision and scale. Integer values use Number(18,0) precision without decimal places, while decimal amounts like currency values use Number(18,2) to preserve two decimal places. The migration reads the field configuration from Forms On Fire to determine whether decimals are enabled and applies matching precision in Salesforce.

Forms On Fire date fields map directly to Salesforce Date fields without transformation. Datetime fields, including those that capture submission timestamps automatically, map to Salesforce DateTime fields with the original capture timezone preserved. If Forms On Fire stores timestamps in UTC, the timezone offset is applied so the Salesforce DateTime reflects the correct local time when the submission was created.

Forms On Fire Location fields capture GPS coordinates as separate latitude and longitude values. These map to two custom Number fields (Latitude__c, Longitude__c) or Salesforce's Geolocation compound field if your org has it enabled. Accuracy and altitude values require additional custom Number fields if you need to preserve them.

Photos and signatures captured in Forms On Fire are downloaded from the source API and re-uploaded as Salesforce Files (ContentVersion records) with the parent record ID set to the migrated submission record. File type, original filename, and capture metadata are preserved in ContentVersion fields.

Forms On Fire picklist values map to Salesforce picklist values on the corresponding field. If your team has standardized picklist value sets in Salesforce, we match source values against the existing picklist and flag any unmatched values for manual resolution before migration.

Forms On Fire Data Source fields reference external datasets for dynamic picklist values. In Salesforce, these require either a custom picklist with static values (for small datasets), a custom object with lookup relationship (for large/reference datasets), or a reintegration of the source system. We flag Data Source fields and document the data volume per field.

Scanned barcode and QR code values are text strings. These map to Salesforce custom Text fields. The original data name from the Forms On Fire field is preserved as the Salesforce field label; the scanned value stores as the field value.

Files uploaded by form submitters through Forms On Fire's attachment field become Salesforce Files linked to the parent submission record. We preserve the original filename, file extension, and file size. Large files (exceeding Salesforce's 25MB limit) are flagged and require either chunking or external storage linking.

Forms On Fire captures metadata per submission that isn't stored in form fields — submitter email (if not a form field), page URL where the form was embedded, and form version. These require custom fields on the Salesforce target object (e.g., Source_Email__c, Form_Version__c, Page_URL__c) if you want to preserve them.