Migrate from Forms On Fire to HighLevel

Each form submission becomes a HighLevel Contact. The submission's respondent email maps to Contact.email. If no email exists, the submission creates a Contact with a placeholder email and the original submission identifier stored in Source_Submission_ID__c. Submission timestamps are preserved as a custom datetime field, and duplicate detection uses the source identifier to avoid creating duplicate Contacts during subsequent imports.

Standard contact fields map name-for-name: firstname → First Name, lastname → Last Name, phone → Phone, email → Email. These are built-in HighLevel fields and require no custom field creation. Address components such as city, state, postal_code, and country also map directly to HighLevel’s built-in address fields, preserving location data without extra configuration. This direct mapping reduces migration overhead and ensures consistency across contact records.

Every non-standard form field—text inputs, numbers, dates, dropdowns—creates a corresponding custom field on the HighLevel Contact. Field type is inferred: text → Text field, number → Number field, date → Date field, dropdown → Picklist. We pre-create all required custom fields before the migration import runs.

Simple Data Sources with <20 rows map to a HighLevel custom pick-list field on Contact, using the Data Source rows as pick-list options. Complex Data Sources with hierarchical rows, multiple columns, or parent-child relationships map to a HighLevel Custom Object with a relationship back to Contact.

Submission metadata that has no native HighLevel equivalent is preserved as custom fields: Submission_ID__c (text), Submission_Date__c (datetime), Form_Name__c (text). Original submission timestamps are preserved for reporting continuity. We also capture the submitting user’s IP address and device type as optional custom fields, which can support compliance logging and fraud detection in HighLevel workflows.

Anonymous submissions without a contact email or name cannot create a valid HighLevel Contact. These are migrated as Custom Object records keyed by submission ID, with all form field values as custom object fields. The relationship back to any identifiable Contact (found via other form submissions) is established via a lookup field.

Forms On Fire users are matched to HighLevel users by email address. If a HighLevel user account does not exist for the Forms On Fire user email, the record is assigned to a fallback owner (your designated admin). User records are flagged for your team to set up HighLevel accounts before go‑live.

Any tags or categories applied to a form submission in Forms On Fire migrate as HighLevel Contact tags. Tags are created in HighLevel if they do not already exist. Tags support segmentation and workflow triggers in HighLevel. Tagging patterns can be used to route contacts into specific pipelines, trigger follow‑up sequences, and enable targeted reporting across campaigns.

Photos, documents, and files attached to a form submission are downloaded and re‑uploaded to HighLevel's file storage, linked to the corresponding Contact record. File size limits and inline image handling follow HighLevel's attachment constraints. All attachments retain their original file name and MIME type, allowing downstream automation to parse or forward content without additional transformation steps.

The form definition itself—the layout, field order, conditional logic, and validation rules—does not migrate. These must be rebuilt in HighLevel's Form Builder. We export a JSON representation of your form schema as a rebuild reference for your HighLevel admin. Each exported JSON captures field IDs, display labels, data types, and any data‑source bindings, providing a complete blueprint for manual recreation.

Forms On Fire conditional field rules, skip logic, and field validation have no direct HighLevel equivalent. These use cases are handled via HighLevel Workflow triggers (Form Submitted) and conditions. We document the existing rules as a workflow specification for your team to rebuild.

Forms On Fire webhook URLs, Zapier connections, and third‑party integration endpoints are platform‑specific. We document the integration configuration so your team can re‑establish these connections in HighLevel's Integrations and Webhooks sections. For each endpoint we record the HTTP method, authentication headers, payload structure, and retry policy, giving developers a clear checklist when configuring the new integrations.