Migrate from Certainly to Zendesk

Certainly Flows with dialogue branches, conditional logic, and user response options do not map to a single Zendesk object. We extract the flow structure as a JSON representation and map individual response nodes to Zendesk Macros (saved replies with dynamic content). Conditional branches and routing logic require recreation as Zendesk Triggers and Automations scoped to ticket creation and status-change events. We document every flow branch, condition, and fallback action in a written inventory for the customer's Zendesk admin to rebuild.

Intents and their training utterances export from Certainly as structured data but the trained NLU classifier does not transfer. Zendesk has no native NLU object; teams either use Zendesk AI (a separate add-on with its own intent configuration) or rebuild the bot layer using a third-party chatbot platform. We preserve all intent names, training phrases, and entity references in a structured CSV and provide a retraining guide for the destination NLU. Without retraining, the bot's classification accuracy degrades significantly.

Custom entities and slot types from Certainly (e.g., product names, order IDs, account types) map to Zendesk Custom Fields on the Ticket object. We assess each entity's type — text, numeric, regex pattern, or list — and recommend the equivalent Zendesk field type (text, number, dropdown, or tag). Regex-based entities and pattern-matching rules in Certainly have no direct Zendesk equivalent and must be converted to text field validation rules or handled in a pre-processing step by a Zendesk admin or integration developer.

Static response texts, rich message templates, and conditional response blocks export cleanly from Certainly as structured data. We map these to Zendesk Macros organized by macro group matching the original flow names. Macro placeholders (e.g., {{customer_name}}, {{order_id}}) migrate as Zendesk dynamic content placeholders. HTML-formatted responses are preserved as macro body content with formatting intact. Macro attachment references migrate as linked file attachments in Zendesk.

The Zendesk connector configuration inside Certainly — including ticket creation triggers, field mappings from chatbot context to ticket fields, and handoff rules — does not export automatically. We document the complete integration settings during discovery: which flows trigger ticket creation, which Zendesk fields are populated from chatbot context (e.g., customer email, intent, extracted entities), and what happens on escalation. The customer's Zendesk admin uses this documentation to configure native Zendesk Triggers, Targets, and integrations post-migration.

Historical chat transcripts from Certainly map to Zendesk Tickets with comments. Each conversation session becomes a Zendesk Ticket; individual message turns map to public or private comments on the ticket. We map session IDs, timestamps, agent attribution, message direction (user/bot/agent), and resolution status to the equivalent Zendesk ticket fields. Where the destination is a new Zendesk instance without a conversation-log object, we archive full transcripts as CSV/JSON alongside the ticket migration.

Customer profiles from Certainly (end-user name, email, phone, custom attributes) map to Zendesk End Users (requesters) on Tickets. Agent profiles and team assignments from Certainly's routing rules map to Zendesk Agent profiles with matching roles. We resolve agents by email against the Zendesk User table and flag any unmapped agents for admin provisioning before the ticket import phase.

Bot performance metrics, intent accuracy scores, conversation deflection rates, and session summaries export from Certainly as structured reports. Zendesk does not have a native object that ingests external bot analytics. We archive these files as CSV/JSON in a named storage location alongside the migration deliverables, labeled with the export date and bot version. The customer's analytics team can import these into a BI tool for historical trend analysis.

If Certainly holds custom data records (e.g., subscription tiers, product references, policy IDs) linked to customers, we assess whether these map to Zendesk's new Custom Objects model (field-based schema, lookup relationship fields, one-to-many relationships) or to Zendesk Ticket Custom Fields. Legacy custom objects with nested or hierarchical data must be redesigned into separate Zendesk objects with lookup fields because the new model does not support nested objects.

Certainly's fallback policies — what happens when intent confidence falls below threshold — and handoff rules governing escalation to human agents do not have a direct Zendesk equivalent. We extract the current fallback configuration (fallback intent, response text, escalation trigger conditions) and document it for the Zendesk admin to implement as a combination of SLA Policies, Assignment Rules, and Agent Copilot settings in Zendesk. This documentation is delivered as part of the integration settings inventory.