Migrate from Inspection Files to Mailchimp

The inspector's user profile in Inspection Files maps to a Mailchimp contact. Email address, first name, last name, and phone number transfer directly. The inspector's role (Admin, Inspector, Viewer) does not map to any Mailchimp field — it is stored as a custom merge field for reference.

Inspection Files sites represent physical locations or facilities. In Mailchimp, each site becomes a tag applied to all contacts at that location, plus a site reference stored in a custom merge field (TEXT type) on each contact record so the site name is visible inline.

Assets in Inspection Files (equipment, vehicles, structures) map to a custom merge field (AssetList__c as TEXT) listing all asset IDs or names associated with a contact. If an inspector is assigned to a specific asset, that asset ID also appears as a tag on the contact for segmentation in Mailchimp.

Each inspection record (date, status, result, findings) has no native equivalent in Mailchimp. We serialize the last N inspection results as a JSON string in a custom merge field on the contact, and tag the contact with the most recent inspection status (e.g., Passed, Failed, Due) for audience segmentation.

Individual checklist responses (pass/fail per item, comments, photo references) are too granular for Mailchimp's flat contact model. They are not imported as individual fields. Instead, the overall inspection result (Pass/Fail/NA count) is mapped; detailed checklist data is exported to a CSV archive referenced by the inspection ID.

Inspection templates define the type of inspection performed. In Mailchimp, the template name becomes a tag applied to all contacts associated with inspections using that template — enabling segmentation by inspection type without modifying Mailchimp's schema. This approach preserves the original inspection classification while keeping the Mailchimp contact record clean and searchable.

Action items and follow-up tasks from inspections have no native Mailchimp equivalent. We attach them as contact notes (preserving the original creation date and assignee) and apply a tag (e.g., FollowUp-Required) to surface contacts needing attention in the Mailchimp audience.

Photos and PDFs attached to inspection records are re-hosted to a FlitStack-managed storage bucket. A URL reference is stored in a custom merge field (InspectionEvidence__c) on the associated Mailchimp contact. Mailchimp does not host files natively — these references point externally.

Next inspection due dates map to a custom DATE merge field (NextInspectionDue__c) on the contact. If a due date is overdue, we apply a tag (Inspection-Overdue) for use in Mailchimp Customer Journey automations that trigger reminder emails. This enables proactive outreach before issues escalate and supports scheduled follow‑up campaigns.

Inspection Files supports custom fields on assets, locations, and inspection records. Each custom property requires a corresponding merge field in Mailchimp. FlitStack creates the merge field on the Mailchimp audience before import and maps values by data type — text to TEXT, numeric values to NUMBER, dates to DATE, and pick-list values to radio or dropdown merge fields.