Migrate from Solitics to Twenty CRM

Solitics user profiles aggregate attributes, transaction history, and behavioral events from all integrated sources into a unified record. We split the profile into Twenty People (individual contact data: name, email, phone, behavioral attributes) and Company (organization data: company name, domain, industry attributes). The split is determined by whether the Solitics profile holds individual or organizational identity. Custom profile attributes from Solitics map to custom fields on Twenty People or Company that we pre-create during schema setup. Any company-level attributes stored within a Solitics profile that has no individual contact identity become a Company-only record in Twenty.

Solitics raw events (registration, deposit, withdrawal, trade, bet, login, and any custom event types) are first-class objects with timestamps and event properties. We migrate event sequences as activity records in Twenty: Task records for discrete event types with ActivityDate set to the original timestamp, and Note records for events with rich property payloads that require structured body content. The full event sequence is preserved in chronological order. Custom event schemas discovered during the schema pass determine which events map to custom task fields versus Note body content.

Solitics segments are live, rule-based definitions built from profile attributes and behavioral conditions. We export segment rule logic as structured documentation (rule tree with conditions, operators, and values). In Twenty, segments translate to a combination of Tags applied to People records and custom field filter combinations that replicate the original segment membership logic. The customer decides during scoping whether to pre-apply segment membership as Tags at migration time or rebuild the segment rules using Twenty's filter and view system post-migration.

Solitics user journeys define automated workflows triggered by events or segment membership, with entry conditions, branching logic, delay rules, and channel steps. Twenty's workflow builder supports record-triggered automations but does not replicate Solitics' event-triggered journey model. We export all active journey definitions as structured documentation (trigger event, each step's action type, delay configuration, and branch conditions) so the customer's team can rebuild them in Twenty's workflow builder or via an external automation layer.

Solitics campaigns are containers for content assets, scheduling, and audience targets. We export campaign metadata (name, status, targeting rules, channel assignment, and performance history) as Note records attached to the relevant People records in Twenty. Channel-specific content bodies (email copy, SMS text, push notification copy, WhatsApp templates) are exported as structured content for the customer's team to recreate in Twenty's channel tooling or an external tool. Solitics campaign performance metrics migrate as a separate data table for reference.

Solitics Smart Gamification stores mission definitions, loyalty point balances, widget configurations, and badge or achievement rules as platform-native objects with no common export format. We export the complete gamification configuration as a structured inventory documenting every mission rule, point balance schema, badge definition, widget setting, and achievement threshold. This inventory serves as the specification for the customer's team to rebuild gamification mechanics in Twenty using custom objects and workflows or an external loyalty platform.

Solitics integrations with external systems (trading platforms, sports feeds, bonus engines, back-office databases) are configured connections rather than data records. These do not migrate. We document every active integration: its data flow direction (push or pull), the endpoint or credential it uses, the polling interval or webhook configuration, and the Solitics object it populates. The customer's technical team uses this inventory as a re-integration checklist to rebuild connections via Twenty's REST API or GraphQL endpoint.

Solitics custom event types beyond the standard set are discovered during the schema pass and exported with their property definitions. Each custom event schema becomes a set of custom fields on the relevant Twenty object (typically People for behavioral event properties). If the custom event has a payload structure that cannot be flattened into standard fields, we store it as structured Note body content with a custom field indicating the event type for post-migration filtering and reporting.

Solitics built-in analytics, custom KPI dashboards, and campaign performance reports are exported as definition documentation (report name, metric definitions, filter logic, date ranges, and historical data export where accessible via API). Twenty's reporting system is available but does not replicate Solitics' behavioral analytics. We deliver a written inventory of every report with its metric definitions so the customer's team can rebuild equivalent reports using Twenty's standard reporting, a connected BI tool, or a data warehouse export.

Content assets in Solitics — email templates, SMS message bodies, push notification copy, WhatsApp templates, in-app widget copy — are exported as structured content files. Localization settings and A/B test variants are preserved as metadata within those files. The sending infrastructure (SMS sender IDs, WhatsApp Business account, push certificates, email sending domains) does not transfer and must be re-registered in Twenty or the customer's chosen channel tool. We provide a channel audit checklist documenting every active asset and its configuration metadata.

Journey owners, campaign managers, and team-level access controls in Solitics export as user references. Twenty separates People (contact records) from Members (workspace users). We match Solitics owners by email to Twenty Members, resolving the owner reference on migrated records. Solitics does not expose a full user management API, so owner extraction relies on the owner_id fields present on records; we flag any owner with no resolvable email address in a reconciliation queue for the customer's admin to resolve before migration begins.