Migrate from Comarch Field Service Management to Twenty CRM

Comarch customer accounts map directly to Twenty Companies. Customer name, address, industry, and annual-revenue fields translate to Company.Name, address fields, Company.industry, and Companyemployees where those exist in the Comarch schema. Primary contact links become Person records with a companyId relation.

Each Comarch customer contact becomes a Twenty Person record. Email, phone, job title, and the contact's role on the service account are mapped to the corresponding Person fields. Multiple contacts per account collapse to individual Person records all linked to the same Company.

Comarch technicians map to Twenty People records flagged with a custom Role field set to 'Technician'. Their skill certifications, service areas, and availability zones become custom select and multi-select fields on the Person record so dispatch teams can reference them after migration. Owner resolution by email matches technician email to an invited Twenty Workspace Member.

Comarch service locations are distinct from the customer account — a single customer may have multiple sites. Each service location migrates as a separate Twenty Company record with the customer account linked via a Parent Company field or a custom Account_Reference__c field for traceability back to Comarch.

Comarch work orders carry structured data (status, priority, SLA deadline, work description, assigned technician, parts used, time spent) that has no single CRM equivalent. FlitStack merges this into a Twenty Task with custom fields for status, priority, SLA_deadline__c, and technician assignment, while the full work-order description and resolution notes are appended as a linked Note with the original Comarch work-order ID.

Comarch asset records (equipment name, serial number, installation date, service history) have no standard Twenty CRM equivalent. FlitStack creates a custom Asset object in Twenty with fields mirroring the Comarch asset schema. Active assets link to the service-location Company record via a companyId relation.

Comarch parts-used line items on work orders are split: parts that map to a product catalog become entries in a custom Inventory Item object; low-value or one-off parts are embedded as a text block in the linked Note on the Task. This prevents an explosion of small inventory records in Twenty if the Comarch catalog is large.

Comarch service contracts with recurring revenue become Twenty Opportunities. Contract value maps to Opportunity.amount, contract start and end dates map to CloseDate with a custom Contract_Start__c field, and the service level (e.g., Gold, Silver) becomes a custom select field. Open contracts route to the relevant Company record.

Comarch SLA timers and escalation policies are FSM logic, not data — they do not migrate. The SLA tier (response time, resolution window) is preserved as a custom text field SLA_Tier__c on the Task for reference, but the countdown logic must be rebuilt in Twenty's workflow builder or via a third-party SLA monitoring integration.

Comarch documents attached to work orders or assets are exported as file references and re-hosted in Twenty's note attachments. If the Comarch export delivers inline binary files, FlitStack re-uploads them to the linked Task or Note record. File size limits from the Comarch export format are honored during re-upload.

Comarch user records are resolved by email against Twenty Workspace Members. Your team must be invited to Twenty before the migration runs — unresolvable owners are flagged and assigned to a fallback owner. Comarch permission sets and role hierarchies do not transfer; those must be reconfigured in Twenty's Settings → Permissions.