Migrate from Comarch Field Service Management to Freshsales

Freshsales has no native work order object — FSM data requires Deal custom fields

Comarch FSM work orders contain FSM-specific properties — priority, SLA deadline, service type, scheduling policy, technician skill requirements, parts used — that have no direct Freshsales Deal field equivalents. Freshsales natively stores deal name, value, stage, close date, and owner only. We map all FSM work order properties to Freshsales custom fields on the Deal (Work_Order_ID__c, Priority__c, Work_Order_Type__c, Service_Type__c, Scheduling_Policy__c, Scheduled_Start__c, Actual_Start__c, Actual_End__c, Duration_Minutes__c). Freshsales custom fields require the Pro or Enterprise plan. Planning which FSM properties to carry forward — and which to treat as reference-only — is a migration design decision made during the audit phase.

Technician skill profiles and FSM scheduling logic have no Freshsales equivalent

Comarch FSM technicians carry skill profiles, certifications, travel zones, availability windows, and routing preferences used by the automated scheduling engine. When we map technicians to Freshsales Users (by email match), those skill profiles and scheduling attributes do not transfer. Freshsales has no scheduling engine — territory management (Pro plan) handles geographic assignment but not skill-based routing or SLA-driven scheduling. If your team relies on Comarch's automated dispatch, those routing rules must be rebuilt in a separate FSM tool or migrated to Freshsales territory + assignment rules manually. We preserve the Comarch scheduling policy name as a text field on the Deal for reference during rebuild.

Comarch workflows and FSM automation rules cannot migrate to Freshsales

Comarch FSM workflow rules handle FSM-specific triggers — work order routing based on location and skill, SLA escalation timers, automatic status transitions, customer notification on technician dispatch. Freshsales basic workflow rules handle sales-cycle automation (deal stage changes, task creation, email triggers) but cannot interpret Comarch FSM event logic. Any Comarch workflow with a FSM-specific trigger — such as 'route work order to technician with matching skill within 10-mile radius when SLA < 2 hours' — will not function in Freshsales. We document every Comarch workflow definition during the audit phase and deliver it as a rebuild reference for your Freshsales admin or a dedicated FSM tool.

FSM asset records require a custom module in Freshsales

Comarch FSM asset records — equipment name, serial number, model, warranty expiry, installation date, linked customer, and maintenance history — have no Freshsales native equivalent. Freshsales does not include an asset management object in its standard schema. We migrate these records to a Freshsales custom module (Asset__c) with a link to the parent Account. Custom modules require the Pro or Enterprise plan. Asset-to-work-order linking is preserved via the Work_Order_ID__c field on the Asset custom module. If your Comarch setup includes multi-level asset hierarchies (parent equipment with sub-components), those hierarchies require a custom relationship design in Freshsales that we deliver as part of the schema plan.

Comarch FSM integrations must be rebuilt for Freshsales

Comarch FSM integrates with ERP, billing, and CRM systems via the Comarch Integration Hub — this is an enterprise middleware layer specific to Comarch's architecture. Freshsales integrations connect via the Freshworks Marketplace, REST API, or webhook triggers. Any Comarch integration — whether to an ERP, accounting system, or third-party dispatch tool — must be rebuilt from scratch in Freshsales. We document the Comarch integration endpoints and data flows during the audit so your Freshsales admin or integration developer has a reference specification. Third-party middleware (Zapier, Make) can bridge some gaps but FSM-specific data flows may require custom API work.