Migrate from Field service software to Twenty CRM

Field service software customer contact records map directly to Twenty's People object. Name, email, phone, job title, and address fields migrate as-is. Multiple service locations per customer collapse to the primary contact address; secondary locations surface as address fields on the associated Company record.

Field service software company or account records map to Twenty Companies. Company name, domain/website, industry, employee count, and annual revenue migrate as standard Company fields. Service location addresses attach as address fields on the Company record. Parent-company hierarchies map to the Twenty Company relation if available.

Work orders are the most complex mapping in this migration. Twenty has no native work order object. We create a custom WorkOrder object in Settings → Data Model before migration. Work order fields (job type, status, priority, description, assigned technician, hours spent, parts used) map to WorkOrder fields. Closed work orders with resolved status migrate as completed Tasks or historical WorkOrder records.

Field service software often stores multiple service locations per customer — each with its own address, site contact, and access notes. We merge the primary service location into the Company record's address fields and create a custom ServiceLocation object for secondary sites with a relation back to the primary Company.

Field service software asset records (serial number, model, install date, warranty expiry, maintenance schedule) have no equivalent in Twenty's standard objects. We create a custom Asset object with fields for serialNumber, modelNumber, installDate, warrantyExpiry, and a relation to the Company (customer) record. Historical service events on the asset link to WorkOrder records.

Service contracts and SLAs map to a custom ServiceContract object in Twenty. Fields include contractType, startDate, endDate, renewalDate, and value. Active contracts link to the associated Company record. Contract line items or included service allowances require a separate contractLine custom field or a related ServiceContractLine object.

Field service technicians and dispatchers map to Twenty Workspace Members. Email addresses match between systems for owner resolution. Technician certifications, skills, and zones (common in FSM) cannot map to standard Twenty fields — we create custom fields (skills, serviceZone) on the WorkspaceMember object if needed, or flag for post-migration configuration.

Field service invoice records — including line items, amounts, payment status, and linked work orders — map to a custom Invoice object. We preserve invoiceNumber, invoiceDate, totalAmount, and status. Tax amounts and payment method require custom fields. Invoice-to-WorkOrder linkage uses a relation field on the Invoice object pointing to the custom WorkOrder object.

Free-text notes on work orders, customer records, or service locations migrate as Twenty Notes attached to the relevant record. Original timestamps and author information are preserved. Rich-text formatting is simplified to plain text or retained as-is depending on the source export format.

Field service software file attachments — photos, signed forms, PDFs — are downloaded and re-uploaded to Twenty's file storage. File size limits depend on Twenty's hosting configuration. Inline images in notes are extracted and rehosted. Large attachment volumes may require separate file hosting (S3, GCS) with URL references in the migration.

Field service software scheduling boards — with drag-and-drop job assignment, technician routes, and real-time dispatch — have no equivalent in Twenty CRM. The scheduling data (which job was assigned to which technician at which time) can be preserved as historical Task assignments or WorkOrder records, but the live scheduling interface must be rebuilt using Twenty's workflow builder or a third-party scheduling integration.

Field service software custom fields on any object migrate as custom fields on the corresponding Twenty object. All custom fields must be created in Settings → Data Model before CSV import or API ingestion. We include custom field creation in the migration plan; custom field count directly affects pricing.