Migrate from Myndbend Process Manager to Freshdesk

Parent tickets are standard Zendesk tickets with Myndbend metadata attached. We read all native Zendesk ticket fields (subject, description, status, priority, requester, assignee, created_at, updated_at) and write them as Freshdesk Tickets with the same values. Myndbend's approval status (pending, approved, denied, skipped) is stored in Myndbend's own metadata store — we read this via Zendesk API and write it to a Freshdesk custom field mpm_approval_status__c. Any Myndbend custom fields referenced on the parent ticket are mapped to their Freshdesk custom field equivalents after cross-referencing the field ID translation table built during extraction.

Freshdesk has no native hierarchical child ticket model. We recreate the parent-child relationship using a Freshdesk custom field parent_ticket_id__c that stores the Freshdesk ticket ID of the linked parent, plus a custom field child_blocking_enabled__c set to true for tickets that were parent-blocking in Myndbend. A note on the parent ticket documents the child ticket IDs. Tickets that were created automatically from Myndbend Ticket Templates carry over their template-derived field values; the Advanced Properties JSON is parsed per template and the field ID references are translated to Freshdesk custom field names.

Approver assignments live as Myndbend metadata on each ticket, referencing Zendesk user IDs or end-user emails. We extract every unique approver across all tickets, resolve their identity via the Zendesk Users API, and map them to Freshdesk Agents by email match. Approval status per approver (approved, denied, pending, skipped) is written to a Freshdesk custom field approver_status__c and a note record on the ticket naming each approver and their decision timestamp. Approvers who are not yet Freshdesk Agents are held in a reconciliation queue for the customer's admin to provision.

Approval Groups are named collections of approvers managed in Myndbend admin settings. We extract group membership (group name, agent email per member) and replicate in Freshdesk as either Freshdesk Groups (if the group's purpose is ticket routing) or as a custom field agent_list__c storing a comma-separated list of agent emails for reference. Any dynamic conditional logic driving Approval Group assignment is documented as a Freshdesk Automation rebuild requirement rather than migrated as code.

Myndbend Ticket Templates define default values and Advanced Properties JSON applied when child tickets are created. We extract the template name, default subject pattern, default group assignment, and the full Advanced Properties JSON for each template. The JSON field ID references are parsed and mapped to Freshdesk custom field names. We deliver a written template inventory with the recommended Freshdesk implementation approach: Saved Reply for repeatable reply content, ticket field defaults for subject/status/group, or a Freshdesk Custom App configuration for complex multi-field population patterns.

Myndbend's Advanced Properties JSON uses Zendesk numeric field IDs to set custom field values on child tickets, with parent_copy and parent_placeholder substitution modes. We parse the JSON per template, extract each referenced Zendesk field ID, map it to the equivalent Freshdesk custom field name (created in the destination Freshdesk account before migration), and apply the substitution mode logic during child ticket generation. Any referenced Zendesk field IDs that do not yet have a Freshdesk custom field counterpart are flagged during scoping and must be created before the migration phase.

Myndbend exposes webhook-based actions (add-approvers-by-id, add-approvers-by-email, add-approval-group, execute-approval-flow) that automate approver assignment via Zendesk triggers. Freshdesk has a different automation model (ticket update triggers, time-based automations, custom apps) with no direct webhook action equivalent. We document all active Myndbend webhook action configurations as part of the workflow inventory handoff. The customer's admin rebuilds the logic in Freshdesk Automations or as a Custom App.

Approval Flows is an early-access feature defining multi-step sequential approval chains with revision history. Because EAP features are not guaranteed stable across releases and have no Freshdesk equivalent object, we do not migrate active Approval Flow definitions. We document the current active flow configuration (steps, approvers per step, conditions) as a written specification for the customer's admin to implement in Freshdesk Automations or a Custom App.