Migrate from Myndbend Process Manager to Intercom

Myndbend parent tickets are standard Zendesk tickets with Myndbend approval metadata attached. We extract all native Zendesk ticket fields (subject, description, status, priority, requester, assignee, group, tags) and Myndbend custom properties (approval status, required approvers, current approval chain) via the Zendesk API. In Intercom, these become Conversation records with the original ticket subject as the conversation title, the ticket description as the initial user message, and the approval status stored as a custom conversation attribute. Requester maps to the Contact (via email match), assignee maps to the Admin or Team assignment.

Myndbend child tickets are separate Zendesk tickets linked to a parent via Myndbend's internal reference, with optional parent-blocking enforcement. We extract each child ticket as an independent Intercom Conversation linked to the parent via a custom conversation attribute (myndbend_parent_ticket_id__c) that references the source parent ticket ID for audit traceability. Intercom has no native parent-child blocking model, so the 'parent cannot resolve until child is solved' business rule must be documented for the customer's admin to implement in Intercom Workflows as a condition check on parent conversation closure.

Approver assignments live as Myndbend metadata on each ticket, referencing Zendesk user IDs or end-user emails. We extract all approver records per ticket (approver identity, approval status: pending/approved/denied, timestamp of decision). Approved and denied approvers are stored as tagged Contacts in Intercom (with a custom attribute approval_decision__c and approval_timestamp__c). Pending approvers are stored as Contacts with pending_approval status for the customer's admin to follow up on post-migration. Myndbend-branded approval email decisions (reply-to-email approvals) do not transfer; approvers must re-confirm in Intercom.

Approval Groups are named collections of approvers managed in Myndbend's admin settings. We extract group membership (group name, list of member user IDs and emails) and replicate as static Teams in Intercom. Any dynamic membership rules (conditional group assignment based on ticket field values) are documented for the customer's admin to implement via Intercom Workflows because Intercom has no equivalent dynamic group concept.

Approval Flows (beta) define multi-step sequential approval chains with revision history. This is an early-access feature and stores state in Myndbend's own storage. We map the current active flow definition and approval chain sequence as written documentation with the list of steps, approver assignments per step, and any conditional branching logic. The customer recreates this in Intercom Workflows step-by-step because Intercom has no native multi-step sequential approval gate feature.

Myndbend Ticket Templates define default values and Advanced Properties (custom field settings via JSON) applied when child tickets are created. Advanced Properties reference exact Zendesk custom field IDs which have no Intercom equivalent. We extract every template as a written specification: target ticket fields, default values, Advanced Properties JSON with mapped field names, and conditional creation rules. The customer's admin uses this spec to define Intercom conversation defaults and Workflow-triggered child conversation creation.

Myndbend's Advanced Properties JSON sets custom field values using parent_copy modes or placeholder substitution. We parse the JSON per ticket template, map each Zendesk field ID to its equivalent Intercom custom attribute name (on Contact or Conversation), and flag any custom attributes that do not yet exist in the Intercom destination. Attributes must be pre-created in Intercom before child ticket generation from templates can occur.

Myndbend exposes webhook-based actions (add-approvers-by-id, add-approvers-by-email, add-approval-group, execute-approval-flow, create-child-tickets, update-child-tickets, collect-approvers) triggered by Zendesk rules. These are Myndbend-internal automation primitives with no Intercom equivalent. We document every active webhook action configuration: the Zendesk trigger conditions, the Myndbend action, the payload structure, and the intended outcome. The customer's admin uses this to design equivalent Intercom Workflows.

Myndbend generates branded approval request emails and reminder schedules sent from Myndbend infrastructure, not stored as records. These do not migrate. Approvers must re-register or be re-onboarded to Intercom's messaging channel. We document the email template content (subject, body, approval link URL structure) so the customer's admin can recreate Approvals-related email content in Intercom's outbound message templates.

The Zendesk ticket comments (agent and end-user) associated with Myndbend parent and child tickets migrate as Intercom Message records within each Conversation. Public comments map to user-visible Messages; internal notes map to Intercom's internal notes if the destination workspace uses internal note capability. Threading is preserved by ordering messages by the original Zendesk ticket comment timestamp.