Migrate from Field2Base to Twenty CRM

Each Field2Base form template becomes a Twenty custom object. The form's region definitions map to custom fields on that object. Region types (text, numeric, dropdown, checkbox, camera, signature) map to Twenty field types (text, number, select, boolean, file, file) respectively. Form template name becomes the custom object label and API name.

Submitted form instances map to records in their corresponding Twenty custom object. The submission's primary key ID is preserved as Source_System_ID__c on the Twenty record. Submitted-at timestamp is stored as a custom datetime field for reporting continuity.

Standard Field2Base region types (single-line text, multi-line text, numeric, date) map directly to Twenty's equivalent field types. Field validation rules (required, min/max) are translated into Twenty's field-level constraints at the data model stage.

Pick-list values in Field2Base dropdown regions map to Twenty select-field options. Each dropdown option is recreated as a Twenty select option. If Field2Base supports dynamic option lists, those are flagged as requiring manual configuration in Twenty after migration.

Signature fields store an image or PDF blob in Field2Base. These are exported as file attachments and re-uploaded to Twenty as file-type fields. The original submission timestamp is preserved as metadata on the file record.

Photo and camera regions attach image files. These migrate as Twenty file fields linked to the custom object record. Inline images embedded in submissions are extracted and re-hosted as separate file attachments.

Field2Base GPS regions store latitude/longitude coordinates. Twenty has no native geolocation field type. We store coordinates as a formatted text field (e.g., '40.7128° N, 74.0060° W') or split into two number fields for latitude and longitude. A map integration may require separate rebuild.

Barcode and QR code scan values store as text strings. These migrate as text fields in Twenty. If you use barcode scanning as a lookup trigger, the integration logic must be rebuilt via Twenty's webhook or API workflow.

Field2Base user accounts are matched to Twenty Workspace Members by email address. Unmatched users are flagged before migration. The assignee relationship on form submissions becomes a relation field to the Twenty Member object on the custom object record.

Field2Base workflows (submitted forms → review → approve/reject) have no direct equivalent in Twenty's workflow builder. We export your workflow definitions as a structured JSON reference document. Your Twenty admin rebuilds the logic using Twenty's workflow triggers and conditions based on that reference.

Field2Base's Data Integration Module (CSV, ODBC, SQL exports) and Enterprise Dispatch Module (back-end field population) cannot be migrated. We document the DIM export configurations and EDM field mappings so your developer can re-implement equivalent connections using Twenty's API or webhook triggers.

If Field2Base organizes form templates into categories or folders, we add a custom select field on the target custom object to carry that organizational tag. Twenty's object model doesn't have native folder hierarchies — grouping is handled via views and filters rather than folder structures.

Submissions created via Field2Base Kiosk Mode are standard form submissions with no additional fields. They migrate as regular custom object records. The kiosk-context flag (if stored as a region value) is preserved as a select field option.

Field2Base role-based permissions (admin, form designer, mobile user) are documented in the migration plan. Twenty's role system is permission-set based — your admin configures access levels in Settings → Roles. Permissions must be manually mapped post-migration.