Migrate from Workiz to Salesforce Sales Cloud

Workiz automations do not migrate — they must be rebuilt in Salesforce Flow

Workiz uses a rule-based automation engine with triggers, conditions, AND/OR logic, and time-based delays. Salesforce Flow operates on a fundamentally different automation model (triggered flows, scheduled flows, screen flows, autolaunched flows) that requires manual rebuild. Every Workiz automation — customer reminder notifications, tech routing rules, payment follow-ups, status-change alerts — must be recreated in Salesforce Flow by your admin. FlitStack AI exports all Workiz automation definitions as a structured reference document to accelerate the rebuild. This is not a data migration; it is a separate configuration project. Plan for it before go-live to avoid operational gaps.

Salesforce Field Service Lightning is a separate paid license — without it, there is no native Work Order scheduling UI

Workiz's core value proposition is its scheduling board and GPS dispatch. Salesforce does not include these capabilities in standard Sales Cloud — they are part of Salesforce Field Service Lightning, which requires additional licensing and configuration. Without Field Service Lightning, Work Orders created by the migration will appear as standard CRM records with no dispatch board, no availability calendar, and no geocoded map view. Teams migrating from Workiz must decide during planning whether to add Field Service Lightning or accept a custom-built scheduling interface. FlitStack surfaces this decision point in the pre-migration schema plan so it does not surface as a post-migration surprise.

Workiz file attachments require extraction, re-upload, and file-size compliance

Workiz stores file attachments (photos, signed documents, PDF invoices) as binary blobs tied to job and client records. Salesforce Files require files to be extracted from Workiz and uploaded individually, with a 25MB per-file limit. Jobs with multiple high-resolution photos, video attachments, or large PDF bundles may exceed this limit and require compression or chunking before Salesforce will accept them. FlitStack validates file sizes during the sample migration phase and flags any records that require pre-migration file preparation. Workiz attachments without files (text-only notes) migrate as Salesforce Notes with no size constraint.

Workiz custom fields require Salesforce custom field creation — naming conventions differ

Workiz custom fields use free-form naming without a required suffix convention. Salesforce requires all custom fields to use the __c suffix and enforces unique API names across the entire org. A Workiz field named Priority on Job collides with Salesforce's internal Priority field on cases. FlitStack checks every Workiz custom field API name against the destination Salesforce org's field registry during the mapping phase and appends suffixes or renames fields to avoid conflicts. Custom fields on every object (Job, Client, Lead, Estimate, Invoice) are independently scoped in Salesforce, so a custom field name used in Workiz on multiple objects requires separate Salesforce custom fields on each target object.

Workiz GPS and address data is geocoordinate-based — Salesforce does not natively visualize field tech locations

Workiz tracks field technician locations via GPS coordinates and assigns jobs based on proximity and availability using its Genius Scheduling engine. Salesforce has no native geolocation visualization for technician tracking or job dispatch optimization. Longitude and latitude data from Workiz can be stored as custom geolocation fields on the Work Order record, but Salesforce's standard reporting does not render these as a map view. Teams that rely on real-time GPS dispatch should plan for a Field Service Lightning setup or a third-party dispatch integration (via Salesforce AppExchange) post-migration to maintain operational parity with Workiz's scheduling intelligence.