Migrate from Mobile Worker to Mailchimp

Mobile Worker Worker records map directly to Mailchimp Contacts. Each worker email, phone, and name field transfers as a Mailchimp contact profile field. Workers without email addresses are flagged for manual review before migration. The mapping also captures the worker's original hire date and team assignment as separate fields, preserving tenure and organizational context for segmentation and reporting purposes.

Mobile Worker worker status values (Active, On Job, On Break, Offline, Inactive) have no Mailchimp native equivalent. FlitStack creates a STATUS__c merge field on the Mailchimp audience and maps each status value by name. Tags (e.g., 'On-Job', 'Active-Worker') can also be applied for segmentation.

Mobile Worker Customer records carry company name, site address, and primary contact name. The company name maps to a custom FNAME merge field or a separate ORGANIZATION merge field. Primary contact from the Customer record can merge into the Worker's contact profile if the worker is also a subscriber.

Work orders carry job name, status, location, schedule, and assignment data. Mailchimp has no work-order object. FlitStack summarizes each worker's last N work orders into a JOB_HISTORY__c text field (JSON or plain text) and appends a job-history note to the contact record for reference.

Mobile Worker Assignments link a Worker to a Work Order with a role and status. Assignment roles (e.g., Primary Technician, Helper) become Mailchimp Tags applied to the contact record so campaigns can segment by field-role without a custom object. Status values from assignments also transfer as separate tags, enabling targeting based on whether a worker is currently assigned or available.

Time entries track hours worked per job. Mailchimp has no time-tracking model. FlitStack preserves the most recent time entry date and total hours as TOTAL_HOURS__c and LAST_JOB_DATE__c merge fields — useful for re-engagement campaigns but not for operational reporting. Multiple time entries per worker accumulate into the total hours field, while the most recent entry date reflects the worker's latest activity window.

Mobile Worker site addresses attached to Customers map to Mailchimp's built-in address merge fields (ADDR1, CITY, STATE, ZIP, COUNTRY). Multiple site addresses per customer collapse to the primary address on the contact profile; secondary sites preserved as a custom LOCATIONS__c text field.

Worker profile photos and certifications stored in Mobile Worker cannot live inside Mailchimp. FlitStack downloads each file and populates a PROFILE_URL__c merge field pointing to the re-hosted file URL. Mailchimp does not host these natively — they must live in external storage (S3, Dropbox, etc.).

Mobile Worker custom objects extending Worker (e.g., certifications, equipment assignments) map to Mailchimp custom merge fields. Field types map to merge field types where supported (text, number, date, phone). Long-text custom objects become text fields with content preserved. Array or list-type custom properties serialize into comma-separated or JSON-formatted text values stored in the corresponding merge field for reference.

Mobile Worker job status values (Scheduled, In Progress, Completed, Cancelled) need explicit value-by-value mapping to Mailchimp tags or a STATUS__c merge field. Status color codes or priority levels do not transfer — only the named value is preserved in Mailchimp.

Mobile Worker team or group assignments map directly to Mailchimp Tags applied to each contact. A worker in 'Team Alpha' receives the tag 'Team-Alpha' in Mailchimp. Tags allow segmentation by team for team-targeted campaign sends. Multiple team memberships per worker result in multiple tags, enabling complex team-based audience splits for region-specific or department-focused campaigns.

Mobile Worker may track whether a contact has consented to marketing. This maps to Mailchimp's SUBSCRIBED / UNSUBSCRIBED / ARCHIVED contact status. FlitStack sets status per source value and surfaces any contacts with no opt-in flag for your team to decide before migration.