Migrate from Paradym to Mailchimp

Paradym credential holders map to Mailchimp contacts. The holder's email address stored in Paradym attributes becomes the Mailchimp contact email. Holders without a stored email cannot become subscribed contacts — FlitStack exports them to a reference CSV for manual Mailchimp import.

Each Paradym credential maps as a row linked to its holder contact. Credential type, issuance timestamp, expiration date, status, and issuer DID are stored as Mailchimp merge fields on the holder contact so the contact profile carries the full credential context.

Each unique Paradym credential template generates a corresponding Mailchimp merge field group. The template ID is preserved as the merge field name or tag key so future credentials from the same template route correctly into Mailchimp. FlitStack documents the mapping between each Paradym template name and its Mailchimp merge field counterpart during the audit phase, ensuring consistency across all future credential issuances that flow into the platform.

Paradym nested object attributes like person.name, person.email, or address.city must be split into separate top-level merge fields. Mailchimp has no native nested field support; FlitStack flattens the hierarchy by concatenating the parent key into the field name (e.g., person_name, address_city).

Array-type nested attributes such as nationalities or disclosure_values are split into individual Mailchimp tags or a pipe-delimited merge field value. FlitStack applies a consistent strategy per attribute type documented in the migration plan before data moves. This ensures that array elements are consistently represented whether as individual tags for filtering or as consolidated string values for reporting purposes.

The credential type identifier from Paradym (e.g., KYCAmlCredential, EmploymentCredential) maps to a Mailchimp tag applied to the holder contact. This allows segmenting the audience by credential type in Mailchimp's tag-based filtering. Multiple credentials of different types attached to the same holder each generate their own tag, enabling precise audience segmentation across all credential types held by each contact.

Mailchimp has no native field for decentralized identifiers. FlitStack creates a text merge field named ISSUER_DID and stores the issuer DID string from the Paradym credential record for audit and verification purposes. The ISSUER_DID field is included in all contact exports and audit reports, allowing your team to trace any contact back to its issuing organization without requiring access to the Paradym platform directly.

Paradym presentation records represent a holder presenting a credential to a verifier. This is a point-in-time event with no direct Mailchimp equivalent. FlitStack preserves the most recent presentation timestamp as a merge field and exports full presentation history as a reference CSV.

Paradym credential status values (active, revoked, expired) map to a CRED_STATUS merge field and a Mailchimp tag. Revoked and expired credentials are tagged accordingly to enable immediate filtering of non-active holders; active credentials receive no tag to keep the default contact profile clean and minimize unnecessary tag clutter in the audience.

If multiple Paradym desks issue credentials to the same holder population, FlitStack maps desk identifiers to either separate Mailchimp audiences (preferred for strict data separation) or audience-level tags (preferred for a unified audience with segmentation). The strategy is agreed during scoping.