Migrate from Forms On Fire to Twenty CRM

Forms On Fire submissions containing name, email, phone, and job title map to Twenty's People object. Each submission becomes one People record. The original submission ID is stored in Source_Form_Submission_ID__c for traceability. If a form captures multiple contacts in a single submission, each contact generates a separate People record.

Submissions capturing company name, domain, industry, and address fields map to Twenty Companies. We extract the first company mentioned and create a Companies record; additional company references in the same submission are captured as a custom field for manual resolution.

Forms On Fire stores submission metadata: assigned user, submission date, completion status. These map as direct fields on People — Submission_Date__c (datetime), Assigned_User_Email__c (text), and Submission_Status__c (select). Original create and update timestamps are preserved as custom datetime fields, enabling time‑based reporting and audit trails that reflect the original entry chronology.

Forms On Fire Location fields capture latitude and longitude as separate properties. We combine them into a text field (Location_Coordinates__c) formatted as 'latitude, longitude' for display in Twenty. If your team used location for route planning, the coordinate pair is preserved for reference even though Twenty has no native map view on the free/Pro tiers.

Forms On Fire Data Sources provide lookup rows for Choices and Data fields — think product catalogs, service lists, or region codes. Each Data Source with fewer than 50 rows maps to a Select or Multi-Select field on the target Twenty object. Data Sources with complex row counts or relationships become a custom object in Twenty with Name, Code, and Description fields, then linked via a relation field on the primary record.

Photos, PDFs, and signatures attached to Forms On Fire submissions are downloaded and re-uploaded to Twenty's file storage. Each file is linked to the corresponding People, Company, or custom object record. File size limits from Forms On Fire are respected during export; large photo sets are compressed before import to stay within Twenty's storage constraints.

Forms On Fire forms used to capture field inspection results, safety audits, or job checklists have no direct Twenty CRM equivalent. We create a custom object — for example, Field_Inspection__c — with custom fields mirroring the form's data fields. The People record of the submitting user is linked via a relation field. Form-specific field types (barcode scan, photo, signature) are preserved as text or attachment fields.

Forms On Fire users who created or were assigned to submissions are resolved by email match against Twenty WorkspaceMembers. Unmatched users are flagged before migration — your admin can invite them to Twenty first or assign their records to a fallback WorkspaceMember.

Forms On Fire form layout settings, conditional visibility rules, and field validation logic do not export from the platform. These must be recreated manually in Twenty's Settings → Data Model as custom field configurations and visibility rules. We deliver a field-mapping document that maps each Forms On Fire data name to its Twenty field API name so your admin can reconfigure layouts efficiently.

Forms On Fire Workflows and Process Steps automate routing between users, apply approval logic, and trigger notifications within the platform. These automation definitions cannot be exported and have no direct Twenty CRM equivalent. We export the workflow definitions as a JSON reference document that your Twenty admin can use to rebuild equivalent automations in Twenty's workflow builder.

Forms On Fire Enterprise SSO configuration maps to Twenty's Organization tier SSO settings (SAML/OIDC available on Organization cloud tier and self-hosted). User-level permissions from Forms On Fire do not translate directly — they must be reconfigured in Twenty's workspace permissions model after migration.