Migrate from Fieldy to Freshsales

Fieldy Customers map to Freshsales Accounts (business-level) and Contacts (person-level). The primary contact person on each Customer record becomes a Freshsales Contact linked to the Account. Additional contact persons from the same Customer become secondary Contacts under the Account. If a Customer has multiple site locations, we assign the primary location address to the Account, while secondary addresses are stored in a custom Locations module when available.

Fieldy Jobs map to Freshsales Deals with FSM-specific fields (job status, technician, service type) migrated as custom fields on the Deal. Job name becomes Deal name; job amount becomes Deal amount. Job created date preserved as a custom datetime field since Freshsales CreatedDate reflects migration time, not the original record date.

Fieldy Locations store service-site addresses, site contacts, and access notes. These map to the Account's address fields for the primary site. Secondary or multi-site locations migrate as a Freshsales custom module record linked to the Account — a pattern ClonePartner documents for Fieldy-to-Freshsales migrations requiring multiple addresses per customer.

Fieldy job line items (parts, labor, fees) split based on type. Service items with a unit price and quantity map to Freshsales Products and attached to the Deal via Deal Products. Flat fees or miscellaneous charges without a product catalogue entry map to a custom text field on the Deal, since Freshsales Deal Products require a product catalog entry for each line item.

Fieldy job statuses (Scheduled, In Progress, Completed, Invoiced, Cancelled) have no Freshsales native equivalent. We create a custom pick-list field on Deal to capture the FSM job status alongside the standard Freshsales sales pipeline stage. Stage-history timestamps are preserved as separate custom datetime fields.

Fieldy technician assignment maps to a custom text field on Deal storing the technician name. Where Fieldy technicians also exist as Freshsales users (for accounts where both tools are used), we resolve by email match and store the Freshsales User ID in a lookup field so the assignment is actionable in Freshsales.

Fieldy job photos, signatures, and PDF attachments migrate as files attached to the corresponding Freshsales Deal (for job-specific attachments) or Account (for site documentation). File size limits on Freshsales apply — files over 25MB are split or linked by URL reference.

Fieldy job notes migrate as Freshsales Notes attached to the corresponding Deal. Original timestamps and the note author (matched by email to a Freshsales User) are preserved. Rich-text formatting in Fieldy notes is converted to plain text to match Freshsales Note body format.

Fieldy custom fields on Jobs (custom form fields, service-type tags, SLA flags) migrate as Freshsales custom fields on Deal. Field types map: text fields to text, pick-lists to pick-lists, date fields to dates. Some FSM-specific field types that don't map cleanly to Freshsales field types land as text fields with a note in the mapping workbook.

Fieldy technicians who are also Freshsales users get resolved by email match. Unmatched technicians are flagged before migration — your team decides whether to invite them to Freshsales or assign their records to a fallback owner. No record lands in Freshsales without a resolved owner.

Fieldy workflow rules (auto-assignment, SLA alerts, job-status triggers) have no Freshsales equivalent and do not migrate. We export your Fieldy workflow definitions as a reference document so your Freshsales admin can rebuild them using Freshsales Workflows after migration. The exported document includes trigger conditions, action details, and any conditional logic, allowing your team to recreate each rule with minimal trial and error in Freshsales.

Fieldy integrations (QuickBooks, Xero, payment gateways, GPS/routing tools) have no direct Freshsales equivalent. Freshsales has its own Freshworks Marketplace integrations — these must be configured separately after migration. We flag which integrations are replacements versus which require third-party middleware. For each flagged integration, we provide a brief setup guide that includes required credentials, API endpoints, and sync frequency recommendations to streamline the post-migration configuration.