Migrate from Myndbend Process Manager to Zendesk

Parent tickets are standard Zendesk tickets with Myndbend metadata attached. We read all native ticket fields (subject, description, status, priority, requester, assignee, created_at, updated_at) via the Zendesk Tickets API, extract Myndbend-specific metadata (approval_status, required_approvers, child_blocking_enabled) from ticket-side custom field values or Myndbend webhook payload logs, and populate corresponding Zendesk custom fields on the destination ticket. We preserve Myndbend's 'approval requested' and 'all approved' tags on the ticket record. Parent tickets with open approval chains are flagged in the migration inventory so that the customer's Zendesk admin can re-trigger approval in the destination before closing.

Child tickets are separate Zendesk tickets linked to their parent via Myndbend's internal reference. We preserve the parent-child linkage by writing the parent ticket ID into a custom field on each child ticket (parent_ticket_id__c) and by applying a consistent tagging convention (child-of-{parent_id}) that allows Zendesk views and triggers to filter by hierarchy. Myndbend's 'child must be solved before parent' blocking enforcement is not native to Zendesk; we replicate this as a Zendesk trigger that prevents status change on the parent ticket to Solved when any tagged child ticket remains Open or Pending, using the child-of tag for lookup. Large parent-child trees with multiple nesting levels require careful batch sequencing to avoid rate-limit pressure on the Zendesk API.

Approver assignments live as Myndbend metadata on each ticket, referencing Zendesk user IDs or end-user email addresses. We extract every approver record per ticket from Myndbend's metadata payload, resolve agent Zendesk user IDs directly via the Users API, and resolve end-user email addresses by looking up or creating the corresponding Zendesk end-user. Approvers are written to a multi-user Zendesk custom field (approval_required__c) on the destination ticket rather than as the standard Assignee field, since Myndbend approvers are distinct from the ticket owner. Pending approver decisions on open tickets are noted in a custom field (pending_approvers__c) so that the customer can re-solicit approvals in the destination before the approval chain resumes.

Approval Groups are named collections of approvers managed within Myndbend's admin settings. We extract group membership (group name, member user IDs or emails, conditional rules if applicable) from Myndbend's configuration export and replicate as Zendesk User Groups. Conditional rules — where approvers are added based on ticket field values — require documentation as a separate Zendesk trigger specification rather than a direct migration, since Zendesk Groups are static collections. If a customer's Myndbend setup uses conditional Approval Groups at the Premium tier, we deliver a written mapping of each conditional rule to a Zendesk trigger condition set.

Approval Flows define multi-step sequential approval chains with revision history tracked in Myndbend as of v4.21. We extract the current active flow state and the approval chain step sequence (step number, approver or Approval Group at each step, escalation timer, escalation target) from Myndbend's metadata. The multi-step sequence is reconstructed as a series of Zendesk triggers and conditions: each step becomes a trigger that fires when the previous step's approval is recorded, adding the next approver via the User Field update action. Complex branching logic within Approval Flows that exceeds simple sequential triggers is documented as a separate automation redesign task for the customer's admin. We flag any flow that uses conditional branching, delegation rules, or custom escalation paths as requiring post-migration rebuild scope.

Myndbend Ticket Templates define default values and Advanced Properties JSON applied when child tickets are created from a parent. We extract the template name, default ticket field values, and the full Advanced Properties JSON schema. The Advanced Properties JSON is parsed to identify each referenced Zendesk field ID, which is then mapped to its destination field ID — since field IDs differ between Zendesk instances, we pre-create any missing custom fields in the destination before import. Each template is then reproduced as a Zendesk Ticket Form with matching default field values and required field configuration. Template-level conditional child ticket creation logic (creating child tickets based on parent field conditions) requires Zendesk trigger rebuild documentation rather than direct migration.

Myndbend allows setting custom field values via JSON using exact numeric field IDs, parent_copy modes (copying parent field values to child), or parent_placeholder substitution (referencing parent field values at child creation time). We parse the Advanced Properties JSON structure per ticket template, extract each field ID reference, and map it to the corresponding Zendesk custom field ID in the destination instance. Any custom fields referenced in Myndbend JSON that do not yet exist in the target Zendesk are flagged and must be created before child ticket generation from templates proceeds. The parent_copy mode for copying custom field values from parent to child on creation maps to Zendesk trigger actions that update child ticket fields after creation.

Myndbend exposes webhook-based actions within Zendesk triggers (add-approvers-by-id, add-approvers-by-email, add-approval-group, execute-approval-flow, lock-ticket-fields) that automate approver assignment and workflow enforcement. We read all configured Myndbend webhook actions from the customer's Zendesk trigger configurations, document each action type, its trigger conditions, and its API payload structure, and then deliver a written mapping to equivalent Zendesk trigger + target combinations or Zendesk Automations. Any Myndbend-specific webhook action that calls Myndbend's internal API (not the Zendesk API) is flagged as non-migratable and replaced with a documented Zendesk-native equivalent.

Myndbend generates branded approval request emails and reminder schedules sent from Myndbend infrastructure, not stored as records. These do not migrate — email content, send timestamps, and approval decisions made via email reply are Myndbend-specific and tied to Myndbend's sender domain. We deliver a written specification for Zendesk macros that replicate the approval request email template using the customer's own domain, plus Zendesk triggers that send these macros when an approval is requested. Any approver who received an email with an approve/deny/request-more-info link in Myndbend must re-initiate or receive a new approval request in Zendesk.

Ticket comments made by agents and requesters are standard Zendesk ticket records accessible via the Zendesk Comments API. These migrate as standard ticket comments with author, timestamp, and body preserved. Myndbend-specific internal comments (marked as Myndbend comments rather than standard Zendesk comments) are flagged as requiring a custom field or tag to preserve the distinction in the destination, since Zendesk does not have a native comment type for app-generated internal notes.