Migrate from Re:Desk to Zendesk

Re:Desk Members (individual residents with contact details, membership type, expiration dates, and custom fields) map to Zendesk Users (the requester contact record). We use email as the dedupe key and preserve membership type as a custom user field. If the Re:Desk customer uses Organizations to group members by household, family plan, or program cohort, we map to both User and Organization with the Organization lookup set during migration. Member status values (active, expired, suspended) map to Zendesk user tags and custom fields rather than lifecycle stages since Zendesk does not have a Contact Lifecycle model.

Re:Desk Programs (classes, leagues, activities with registration limits, schedules, and pricing) map to Zendesk Custom Objects named 'Program' or 'Activity' on Suite Enterprise ($169/agent/mo). The Custom Object schema includes standard fields for program name, schedule, capacity, pricing, and registration status, plus custom fields for Re:Desk-specific attributes. Suite Growth and below do not have Custom Objects; Programs in those tiers map to Organization records with extended custom fields or remain as a documented data reference outside Zendesk's operational schema.

Re:Desk Facilities (reservable assets such as courts, fields, rooms, and pools with availability rules) map to Zendesk Custom Objects named 'Facility'. Facility details including location, asset type, capacity, and availability schedule migrate as Custom Object records. Reservations link to Facility Custom Objects via lookup relationships on Suite Enterprise. On Suite Growth and below, Facilities map to Organization records with location fields used as the primary identifier.

Re:Desk Reservations (facility and rental bookings with date ranges, time slots, and member or guest associations) map to Zendesk Tickets labeled by type (e.g., 'Facility Reservation Request') if the customer wants front-desk staff to manage reservations as support requests. Alternatively, Reservations map to a Custom Object 'Reservation' with a lookup to the Facility Custom Object on Suite Enterprise. We determine the strategy during scoping based on whether the customer wants reservation management inside or outside Zendesk's ticket queue. We preserve full reservation history including cancelled and past reservations if scoped.

Re:Desk Point-of-Sale Transactions (concessions, fee collection, registration payments with line items, payment method, timestamp, and attending staff) map to Zendesk Custom Objects named 'Transaction' on Suite Enterprise. Transaction records include the payment amount, method, associated member (User lookup), program or facility (lookup), and staff agent reference. Transactions do not map to Zendesk Tickets because tickets represent support requests, not financial records. On Suite Growth and below, Transaction data is documented as a reference export outside the Zendesk operational model.

Re:Desk Invoices (for registrations, rentals, and POS purchases with headers and line items) map to Zendesk Custom Objects named 'Invoice' on Suite Enterprise. Invoice status mapping (paid, pending, refunded) transfers as a custom picklist field. Invoice PDF attachments migrate as ContentDocument linked to the Invoice Custom Object record. On Suite Growth and below, Invoice data is exported as reference records outside Zendesk's standard schema.

Re:Desk Check-in and Attendance records (facility entry and program attendance with timestamps and member references) map to Zendesk Custom Objects named 'Attendance' on Suite Enterprise. We flag gaps in attendance data noted during discovery since Re:Desk has documented limitations on real-time check-in and check-out tracking. Attendance Custom Objects link to the relevant Facility or Program Custom Object via lookup relationships. On Suite Growth and below, attendance data is documented as a reference export.

Re:Desk Staff accounts (Administrator, Staff, Front Desk roles) map to Zendesk Agents with corresponding permission sets. We extract role assignments from Re:Desk and map them to Zendesk roles: Re:Desk Administrator maps to Zendesk Admin, Staff maps to Agent, and Front Desk maps to Agent with restricted view access. We resolve agents by email match against the Zendesk destination and hold any unmatched staff in a reconciliation queue for admin provisioning before record import.

Re:Desk custom fields on Members and Programs map to Zendesk custom fields on the equivalent User and Custom Object records. We discover custom field definitions during scoping, capture data types (text, number, date, dropdown, checkbox), and apply Zendesk's field type equivalents during migration. Custom field values on individual records transfer as field-level data. If a Re:Desk custom field has no Zendesk equivalent (e.g., sport-specific attributes), we create a matching Zendesk custom field and flag it for admin review.

Documents attached to Re:Desk member records, programs, or reservations export as binary blobs with filename and association metadata preserved. These migrate as Salesforce Files (ContentDocument) linked via ContentDocumentLink to the parent Zendesk record (User, Custom Object, or Ticket). File size limits in Zendesk are 20 MB per file by default on most plans, configurable upward on Enterprise. We flag files exceeding Zendesk's size limit during scoping for customer decision on splitting or archiving.