Migrate from Re:Desk to Salesforce Service Cloud

Re:Desk Member records map to Salesforce Contact with custom fields added to hold recreation-specific properties: membership_type__c (from member type), membership_status__c (active, expired, suspended), expiration_date__c, and any organization-defined custom fields. Member status values (active, expired, pending) map to Salesforce Contact Source or Lifecycle Stage custom fields since no direct equivalent exists. Email, phone, address, and emergency contact fields map directly to standard Contact fields. Member photo or ID document attachments migrate as ContentDocumentLink records attached to the Contact.

Re:Desk Programs (classes, leagues, activities) do not have a direct Salesforce standard object equivalent, so we pre-create a Program__c custom object with fields matching the Re:Desk program schema: program_name__c, program_type__c (from program category), registration_limit__c, schedule__c, start_date__c, end_date__c, instructor__c (lookup to Contact or User), and registration_fee__c. We preserve program registration counts by storing enrolled_member_count__c. If the customer uses Cases to track program-related service requests, we configure a lookup from Program__c to Case.

Re:Desk Facilities (courts, fields, rooms, pools) map to a Facility__c custom object since Salesforce has no standard reservable-asset object. Fields include facility_name__c, facility_type__c (court, field, room, pool), capacity__c, location__c (street, city, zip), amenities__c (multiselect picklist), and availability_rules__c (free-text or custom object if complex). Facility reservations from Re:Desk associate with Facility__c records during the reservation migration phase.

Re:Desk Reservations map to a Reservation__c custom object with fields: facility__c (lookup to Facility__c), member__c (lookup to Contact), start_time__c, end_time__c, reservation_status__c (confirmed, cancelled, completed), guest_count__c, and notes__c. Cancelled reservations are migrated with status preserved so historical utilization reporting remains accurate. We use the Salesforce Bulk API with chunking and parent-record resolution to load large reservation histories, resolving Facility__c and Contact lookups before insert.

Re:Desk program registrations (member signups for specific programs) map to ProgramRegistration__c with lookups to Contact (member) and Program__c. Fields include registration_date__c, registration_status__c (registered, waitlisted, cancelled, attended), payment_status__c, and waitlist_position__c. If the customer prefers to track registrations as Cases, we configure a Case-based alternative where each registration becomes a Case with Record Type = Program Registration and custom fields for program and member lookups.

Re:Desk POS transactions (concessions, registration fees, rental payments) map to a Transaction__c custom object with fields: transaction_date__c, transaction_type__c (sale, refund, registration_payment, rental_payment), payment_method__c (cash, card, check), amount__c, line_items__c (free text summary or custom line-item child object), and related_member__c (lookup to Contact). Transaction status (completed, refunded) maps to transaction_status__c. If the customer uses Salesforce Finance and CRM for invoicing, we configure a mapping to Invoice and InvoiceLineItem instead.

Re:Desk Invoices for registrations and rentals map to Salesforce Invoice if the destination org has Salesforce Billing enabled, or to a custom Invoice__c object if not. Invoice__c fields include invoice_number__c, invoice_date__c, member__c (lookup to Contact), amount__c, status__c (sent, paid, overdue, void), and line_items__c. We apply status mapping: Re:Desk paid maps to Salesforce Paid, pending maps to Draft or Sent, refunded maps to Void. The customer confirms during scoping whether Salesforce Billing is in scope or custom object is preferred.

Re:Desk Staff accounts (Administrator, Staff, Front Desk roles) map to Salesforce User records. We resolve by email match against the destination org's User table. Role assignments from Re:Desk (admin, staff, front_desk) map to a custom Salesforce role field or to Salesforce Permission Sets we create and assign during migration. Any Re:Desk staff account without a matching User in the destination org goes to a reconciliation queue for the customer's admin to provision before the user migration phase completes.

Re:Desk attendance records for programs and facilities map to Attendance__c with lookups to Contact (member) and Program__c or Facility__c. Fields include check_in_time__c, check_out_time__c, duration_minutes__c (calculated), program__c (lookup), facility__c (lookup), and attendance_status__c. Research indicates Re:Desk has limitations in real-time check-in and check-out tracking; we export all available attendance records and flag gaps in the data for customer review during scoping.

Documents attached to member records, programs, or reservations in Re:Desk export as binary files with filename, association metadata, and timestamps. We preserve these as Salesforce ContentDocument records attached via ContentDocumentLink to the parent record (Contact for member documents, Program__c for program documents, Facility__c for facility documents, Reservation__c for reservation documents). We flag any files exceeding Salesforce attachment storage limits (25 MB per file) for the customer to store externally and link by URL.