Migrate from Myndbend Process Manager to Zoho Desk

Parent tickets are standard Zendesk tickets with Myndbend approval metadata attached. We read all native Zendesk ticket fields (subject, description, status, priority, requester, assignee, tags, created_at, updated_at) via Zendesk REST API and map them directly to Zoho Desk Ticket fields. Myndbend approval status and required approver count migrate as Zoho Desk custom fields (e.g., Approval Status as a picklist, Required Approvers as a number field). Ticket IDs from Zendesk are preserved in a custom field zendesk_ticket_id for audit reference.

Child tickets are separate Zendesk tickets linked to a parent via Myndbend's internal reference. We map each child ticket to a Zoho Desk Sub-Task linked to the parent Ticket via the parentId relationship. Myndbend's 'child must be solved before parent' blocking behavior has no native Zoho Desk equivalent; we document the blocking rule for the customer's admin to implement as a Zoho Desk Blueprint with a conditional close gate. Parent-child linkage is preserved by resolving the Zendesk parent ticket ID against the migrated Zoho Desk ticket ID.

Approver assignments live as Myndbend metadata per ticket, referencing Zendesk user IDs or end-user emails. We extract all approver records per ticket, resolve each Zendesk user ID to the corresponding agent email in Zoho Desk, and map approver identity to a custom multi-user field Approvers__c on the Ticket. Approval decisions (approved, denied, pending) migrate as a separate custom picklist field per approval step.

Approval Groups are named collections of approvers managed in Myndbend's admin settings. We extract group membership (group name, member email, member role) and replicate as Zoho Desk Departments with agent membership. If the customer's approval logic relies on named Approval Groups rather than individual approvers, we create the Department as the mapping target and preserve the original Myndbend group name in a custom field approval_group_name__c. Any dynamic membership rules (conditional addition by ticket field) do not migrate and require rebuild in Zoho Desk Blueprint.

Approval Flows (Myndbend's early-access multi-step sequential approval chains) store revision history from v4.21 onward. We extract the current active flow state and step sequence (step order, step type, approver assignment mode, timeout, escalation action) from Myndbend's metadata. Zoho Desk's Blueprint builder at Professional tier replicates the multi-step approval concept but requires manual reconstruction. We deliver a written Blueprint design document specifying each approval step, its conditions, and its escalations, and the customer's Zoho admin implements it post-migration. Flows do not migrate as executable code.

Myndbend Ticket Templates define default values and Advanced Properties (custom field settings via JSON) applied when child tickets are created from a parent. We extract the template name, default field values, and Advanced Properties JSON. Advanced Properties reference Zendesk custom field IDs that will not match Zoho Desk field IDs, so we parse each JSON block, identify the referenced field ID, map it to the equivalent Zoho Desk custom field name, and flag any fields that do not yet exist in Zoho Desk and must be created before the template is applied. Templates migrate as Zoho Desk Macros with a written design document for Blueprint template conversion.

Myndbend's Advanced Properties JSON uses Zendesk numeric field IDs with parent_copy, parent_placeholder, and fixed-value modes. We parse the JSON structure per ticket or template, map each Zendesk field ID to its Zoho Desk equivalent custom field (by field name match or explicit ID mapping), and resolve parent_copy references by mapping them to Zoho Desk field-update actions against the linked sub-task. Custom fields that do not exist in the destination are created before migration begins.

Myndbend exposes webhook-based trigger actions (add-approvers-by-id, add-approvers-by-email, add-approval-group, execute-approval-flow) that automate approver assignment via Zendesk triggers. We read all configured webhook actions and map them to Zoho Desk Workflow Rules and Blueprint conditions. Dynamic approver lookup by external ID or group ID has no direct Zoho Desk equivalent and requires custom field normalization or Zoho Creator extension. We document each webhook action's current behavior and recommended Zoho Desk replacement.

Myndbend allows approvers to delegate their approval authority to other users. Delegation records are stored in Myndbend's metadata store. We extract delegation mappings (delegator email, delegate email, scope, expiry) and preserve them as a Zoho Desk custom object or as records in a lookup table that the customer's admin populates post-migration. Delegation logic does not have a native Zoho Desk equivalent and requires admin setup or Zoho Creator extension.

Myndbend approval events (approve, deny, reassign, escalate, timeout) are stored in Myndbend's metadata with timestamps and actor identity. We extract the approval event log per ticket, reconstruct a chronological audit narrative, and write it into the Zoho Desk Ticket as internal comments attributed to the original actor. Original Myndbend approval timestamps migrate to a custom field approval_history_timestamp__c for audit compliance. This preserves the audit trail without native approval history object support in Zoho Desk.

Myndbend supports partial approval settings (one approver required out of all, or all approvers required) per ticket or per workflow. We extract the current partial-approval flag per ticket and map it to a Zoho Desk custom picklist field approval_mode__c with values 'any' or 'all'. The customer's Zoho admin implements the enforcement logic in Blueprint conditions based on this field value.

Myndbend uses tags to communicate state changes between child and parent tickets (e.g., parent-tagged when all children approved). We extract all Myndbend-generated tags from parent and child tickets and map them to Zoho Desk tags by name. Myndbend's field-locking feature (lock fields once approval starts) has no native Zoho Desk equivalent; we document it as a Zoho Desk Blueprint field-readonly condition for the customer's admin to implement.