Migrate from Myndbend Process Manager to HubSpot Service Hub

Myndbend parent tickets are Zendesk tickets with Myndbend metadata attached. We read all native Zendesk ticket fields (subject, description, status, priority, requester, assignee, tags, created_at, updated_at) plus Myndbend custom properties (approval status, required approvers, blocking flag) via the Zendesk API and import as HubSpot Tickets. Myndbend's approval_status property maps to a custom HubSpot ticket property myndbend_approval_status__c with values Pending, Approved, Rejected, Escalated. Any Myndbend metadata referencing a free-tier setup is flagged during scoping because those approval dependencies stop working if the Myndbend app is deactivated.

Myndbend child tickets are separate Zendesk tickets linked to a parent via Myndbend's internal reference. We preserve the parent-child linkage by creating a custom HubSpot ticket property myndbend_parent_ticket_id__c storing the parent's HubSpot ticket ID. Myndbend's child-blocking enforcement (child must be solved before parent) is stored as myndbend_blocks_parent__c boolean. Child ticket content, attachments, and comments migrate directly. Note that HubSpot does not enforce parent-blocking natively; we document the requirement for the customer's admin to implement a HubSpot Workflow that checks child ticket status before allowing parent resolution.

Approver assignments live as Myndbend metadata per ticket, referencing Zendesk user IDs or end-user emails. We resolve each approver by email against HubSpot's contact and user records. Agents on the HubSpot Service Hub instance become HubSpot Users; external approvers who are not HubSpot users are stored as approver email lists in a custom ticket property myndbend_approver_list__c (multi-line text or contact association). We do not create HubSpot Users for external approvers who will not act as service agents.

Approval Groups are named collections of approvers managed in Myndbend's admin settings. We extract group membership (group name, member email list) and replicate as HubSpot User Teams. Teams are created in HubSpot before ticket migration begins so that ticket assignments can reference team-based routing. If the customer's Myndbend setup uses conditional approval groups (Premium and Enterprise tier), we document each conditional rule and deliver a written description for the customer's admin to implement as HubSpot Workflow enrollment criteria.

Approval Flows is an Myndbend EAP feature defining multi-step sequential approval chains with revision history (v4.21+). There is no direct HubSpot equivalent for sequential multi-approver gates. We map the current active flow state and chain sequence to a written inventory document describing each approval step, its triggering condition, assigned approver or group, and escalation path. The customer's admin rebuilds this logic using HubSpot Workflows with enrollment triggers, approval notification actions, and property updates. Approval Flows revision history does not migrate; only the current active state is preserved as a configuration reference document.

Myndbend Ticket Templates define default values and Advanced Properties JSON applied when child tickets are created from a parent. Advanced Properties reference Zendesk field IDs by numeric ID and support parent_copy and parent_placeholder substitution modes. We parse the Advanced Properties JSON per template, resolve each Zendesk field ID to its HubSpot property name (pre-creating the property in HubSpot if it does not exist), and document the template as a HubSpot Workflow that sets property defaults when a child ticket is created. We do not execute automated child ticket creation from templates in HubSpot; we deliver the workflow definition for the customer's admin to activate.

Myndbend Advanced Properties JSON references Zendesk custom field IDs by numeric ID. When migrating to HubSpot, these IDs will not match. We parse the JSON structure per ticket and template, identify each referenced Zendesk field ID, map it to the corresponding HubSpot property (creating it if absent), and apply the resolved values during ticket import. Any custom fields in the JSON that do not yet exist in the target HubSpot portal are flagged with a pre-migration action required.

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. We read all configured webhook actions in the customer's Zendesk instance and document them as a workflow inventory specifying the trigger event, the action type, and the intended approver resolution. The customer's admin rebuilds these as HubSpot Workflows with the equivalent enrollment trigger and action steps.

Beyond Myndbend's approval layer, the underlying Zendesk tickets (subject, description, status, priority, requester, assignee, tags, comments, attachments, internal notes, satisfaction rating) map to HubSpot Tickets. Zendesk side conversations have no native HubSpot equivalent and migrate as private ticket comments. Attachments migrate as HubSpot file attachments on the ticket record. Tags map to HubSpot ticket tags directly.

Zendesk Organizations map to HubSpot Companies. The organization name becomes the company name, domain becomes the website field, and created_at migrates. Organization membership per user maps to a HubSpot Company contact association. We use organization domain as the dedupe key during import.

Zendesk end-users map to HubSpot Contacts. Zendesk agents who will use HubSpot Service Hub become HubSpot Users (required for ticket assignment and inbox access). Agents who will not act as HubSpot users are stored as Contacts with a custom role property. We resolve the split during scoping based on the customer's service team roster.

Myndbend generates branded approval request emails and reminder schedules sent from Myndbend infrastructure. These are transient delivery records, not stored as data objects, and have no migration value. We document the email templates Myndbend used (subject line, body content) as a reference for the customer's admin to recreate as HubSpot email sequences or notification templates. All approvers must be re-enrolled in HubSpot notification routing post-migration.