Migrate from Dashly to Zoho CRM

Dashly Leads map directly to Zoho CRM Contacts. Standard fields (name, email, phone, company name) map to their Zoho equivalents. Custom Lead properties migrate to Zoho custom fields on the Contact module. We inventory all custom properties during discovery, define matching Zoho custom fields (with correct data types: text, numeric, picklist, date, checkbox), and resolve the mapping before import. Dashly Lead source and UTM fields become Zoho Contact custom fields.

Dashly Company records map to Zoho CRM Accounts. Company name maps to Account Name, domain to Website, and industry to Industry picklist. Any custom company properties migrate to Account custom fields. We create the Account before Contact import so that the Account-Contact lookup is satisfied at insert time. Multi-company associations on a single Dashly Lead require resolution: we attach the primary company as Account Name and flag additional associations in a custom field for the Zoho admin to restructure post-migration.

Dashly Conversations do not have a direct Zoho CRM equivalent because Zoho lacks a native threaded conversation object. We split each Conversation into a Task record holding the metadata (status, assignee, source channel, created timestamp, last modified timestamp) and a Note attached to the Task or to the related Contact holding the full message body. This preserves conversation context and ordering. Conversation status (open, resolved, pending) maps to Zoho Task Status values (Not Started, In Progress, Completed). Assignee resolution runs against the User mapping table.

Dashly Messages within a Conversation migrate as separate Task records or as child entries under the parent Conversation Task, depending on the volume. Each message preserves sender attribution (agent name, visitor identifier), message body, timestamp, and delivery channel. We set the Task Activity Date to the original message timestamp to preserve chronological ordering in the Zoho timeline. High-volume message migration (over 50 messages per conversation) batches by conversation_id to avoid individual record timeout.

Dashly User records (agents and admins) map to Zoho CRM Users by email match. We export user email, name, role, and availability status during discovery. Zoho User provisioning is a prerequisite for any record migration because OwnerId references on Contacts, Accounts, Deals, and Tasks must resolve at insert time. Users without an existing Zoho account enter a reconciliation queue for the customer's admin to provision before the relevant migration phase runs.

Dashly Leadbots are structured automation configs with trigger conditions, dialogue trees, and action sequences defined in JSON. We export the full bot configuration as a JSON file. Zoho CRM's workflow automation model (workflow rules, approval processes, blueprints) does not share the same trigger schema as Dashly Leadbots, so automated migration is not feasible. We deliver the exported JSON with a mapping guide that maps Dashly trigger events (page visit, time delay, form submit) to equivalent Zoho workflow triggers. The customer's Zoho admin or a Zoho consultant rebuilds the bot logic manually in the workflow builder.

Dashly triggered message rules (behavior-based outbound sequences) export as structured automation data. The trigger rules, delay settings, message templates, and audience conditions map to Zoho CRM Workflow Rules and Mass Email Templates. We provide the exported data and a written mapping of Dashly trigger types (time-delay, behavioral, event-based) to Zoho equivalent triggers (field update, date-based, form submission). Automated rebuild is outside migration scope because the sequencing and branching logic differs between platforms.

Dashly Knowledge Base articles (title, body content, category, SEO settings) export as structured text with metadata. Zoho CRM has no native knowledge base module, so articles cannot migrate as a native object. If the customer licenses Zoho Desk separately, articles can be imported to the Desk knowledge base with category and tag mapping. Without Desk, we deliver the articles as a structured CSV with HTML body content, and the customer decides where to host the rebuilt knowledge base. Deep SEO field mapping (meta title, meta description, URL slug) is not possible in Zoho CRM without Desk or an external CMS.

Dashly tags applied to Leads, Conversations, or Companies export as flat label arrays. Zoho CRM supports Tags on most standard modules (Contacts, Accounts, Deals, Tasks). We map each Dashly tag to a Zoho Tag of the same label, preserving the association to the relevant record type. Tags with identical names across record types are created once and applied per module. Tag volume is inventoried during discovery to ensure the customer has an appropriate Zoho plan that supports tag-heavy usage.

Dashly custom properties on Leads are defined per-account with data types that include text, number, date, checkbox, dropdown, and URL. We inventory all custom properties during the discovery phase, map each to a Zoho CRM custom field with the equivalent data type on the Contact module, and provision the custom fields in Zoho before migration begins. Multi-select picklist custom properties in Dashly map to Zoho Multi-Select Picklist fields. Custom property ordering and layout assignment is outside scope and handled by the Zoho admin post-migration.

Dashly conversation assignee data maps to Zoho Task Owner (assigned to a Zoho User). Routing rules that assign conversations to specific agents or teams based on conditions export as configuration data. We map the Dashly routing logic to Zoho's assignment rules or workflow field updates where a direct equivalent exists. Complex routing logic with conditional branching requires manual rebuild in Zoho's assignment rule builder.

Dashly visitor session data (page views, referrer, UTM parameters, session duration, behavioral events) is ephemeral and aggregated by Dashly's analytics engine. It is not stored as structured records and has no migratable equivalent in Zoho CRM. We confirm during discovery that no visitor analytics are expected to transfer and document this in the migration scope sign-off.