Migrate from Q Dispatch to Freshsales

Q Dispatch dispatch workflows and scheduling automations cannot migrate to Freshsales

Q Dispatch workflows govern dispatch-board logic: technician assignment rules, job-routing conditions, shift-capacity constraints, and real-time status triggers. Freshsales Workflows automate CRM actions (field updates, email alerts, task creation) but do not replicate dispatch-scheduling logic. Any automated technician routing, capacity-based assignment, or time-triggered dispatch rules must be rebuilt from scratch in Freshsales using Freshsales Workflows or its custom module automation tools. FlitStack exports your Q Dispatch workflow definitions as a structured reference document so your Freshsales admin can rebuild the logic systematically rather than reverse-engineering from memory.

Freshsales has no native work-order object — multi-visit service histories require a Task chain or custom module

Q Dispatch work orders support multi-visit service histories with parts, resolution notes, and per-visit status tracking. Freshsales has no native work-order equivalent — the closest standard object is a Task, which stores a single interaction. A complete Q Dispatch work order with five visits becomes five related Freshsales Tasks ordered by visit date. On Enterprise plans with custom modules enabled, we can create a Work_Order__c module to preserve the parent-child visit structure more faithfully. Planning this decision before migration is essential because the chosen approach determines whether you need Freshsales Enterprise.

Technician assignment requires User provisioning in Freshsales before migration

Q Dispatch technicians are operational users with specialized properties (skills, certifications, service categories) that do not map to standard Freshsales User fields. We match each Q Dispatch technician to a Freshsales User by email, but if a technician email does not correspond to an existing Freshsales user, the technician record cannot be created as a Freshsales User through the migration API alone — your Freshsales admin must provision the user first. We flag unmatched technician IDs before migration so you can provision accounts or assign a fallback owner before the run commits.

Q Dispatch custom fields require Freshsales custom field creation before data loads

Q Dispatch setups frequently include custom fields for service categories, job types, priority levels, parts used, and asset properties. Freshsales requires any custom field referenced in a data load to exist on the target object before the import runs. On Growth and Pro plans, custom fields are supported on standard modules. On Enterprise plans, custom modules allow a dedicated Work_Order__c or Asset__c module. We deliver a pre-migration custom field setup plan that lists every Q Dispatch custom field, its data type, the Freshsales target object, and whether it requires a custom field creation (Growth/Pro) or a custom module (Enterprise).

Freshsales contact lifecycle stages do not automatically track Q Dispatch customer onboarding

Q Dispatch customers enter the system when a service request is created, not through a traditional lead-to-customer funnel. Freshsales Contact lifecycle stages (Subscriber, Lead, Marketing Qualified Lead, Sales Qualified Lead, Opportunity, Customer) assume a sales-driven progression. If you want Q Dispatch customers to land at a specific lifecycle stage in Freshsales, we set a default stage value (typically 'Customer' for existing service accounts) during migration. Any historical stage-transition data in Q Dispatch is preserved as a custom field audit trail since Freshsales does not maintain contact stage-change history natively.