Migrate from Paradym to Twenty CRM

Paradigm holders — the individuals who hold credentials — map directly to Twenty People. Name, email, phone, and job title from the credential subject attributes migrate as standard People fields. Each holder gets one People record with original create timestamps preserved in custom datetime fields.

Paradigm's holder identifier is a UUID assigned to each credential holder in the system. Since Twenty People has no native field to store this external reference, we create a custom text field named Paradigm_Holder_ID__c to preserve the identifier. This enables full traceability back to the original Paradigm record and supports de-duplication logic across multiple migration runs or delta synchronizations.

Paradigm credential issuers — the organizations that issue credentials — map to Twenty Companies. Issuer name, domain, and type map to Company.name, Company.domain, and a custom type field. Multiple credentials issued by the same issuer collapse to one Company record with a credential count custom field.

The Paradigm issuer UUID is the unique identifier assigned to each issuing organization. Twenty Company records have no native field for storing external system identifiers, so we create Paradigm_Issuer_ID__c as a custom text field on the Company object. This field enables cross-system reference, traceability during reconciliation, and delta-sync matching between Paradigm issuer data and Twenty Company records.

Paradigm credentials have no native CRM equivalent in Twenty. We create a custom Credential object in Twenty (on Organization tier or above) with fields for credentialId, type, status, issueDate, expiryDate, holderId (lookup to People), and issuerId (lookup to Company). This is the core structural addition for this migration.

The credential type designation (such as 'VerifiedEmail' or 'ProofOfEmployment') from Paradigm maps to either the name field or a custom type pick-list on the Twenty Credential custom object. Exact type values are preserved exactly as they appear in Paradigm and are fully configurable within Twenty's field settings post-migration.

Paradigm SD-JWT VC schemas define the structural layout of attributes within a credential. The schema identifier URL is migrated as a text field called Credential_Schema__c on the Credential custom object. This preserves the original schema reference so your team can audit the original attribute definitions and validate credential contents against the source schema.

Paradigm tracks credential presentations as verification events — when a holder presented a credential to a verifier. Each verification event becomes a Twenty Task linked to the corresponding Credential record and holder People record. Task subject carries the verification outcome (verified/rejected), and original timestamps are preserved.

Paradigm nested attributes (such as person.name combined with person.address under a 'person' key, or multiple nationalities under a 'nationalities' array) require transformation for Twenty's flat field model. We offer two approaches: individual custom fields for each sub-attribute (recommended when there are up to 10 attributes for clean reporting), or serialized JSON in a Nested_Attributes_JSON__c text field for complex or larger attribute sets.

Paradigm SD-JWT VC credential templates define attribute schemas, validity rules, and revocation settings for issued credentials. Twenty CRM contains no credential template concept — there is no object, field, or configuration in Twenty that models credential issuance templates. We export all Paradigm template definitions as JSON, including nested attribute configurations, template identifiers, and revocation rules, so your identity engineering team can reconstruct them in a dedicated credential issuance platform.

Paradigm presentation templates control which credential attributes are shared during verification and how disclosure formatting is handled. Twenty CRM has no equivalent feature to model selective attribute presentation. These must be rebuilt entirely within a dedicated identity or verification platform, or potentially through Twenty's workflow builder if selective disclosure capabilities are required in your target environment.

Paradigm credential revocation status requires mapping to a custom pick-list field on the Credential custom object with values for Active, Revoked, and Expired. For audit continuity, we also add datetime fields such as Revoked_At__c to capture the exact timestamp when any credential status changed. This preserves the complete revocation timeline from Paradigm in your Twenty workspace.

A Paradigm holder can receive credentials from multiple issuers and an issuer can issue to multiple holders, creating a many-to-many relationship that Twenty's flat object model does not natively support. We model this by creating a People record for each holder, a Company record for each issuer, and a Credential custom object with lookups to both. The Credential object serves as the junction record that connects holders to issuers through their respective credentials.