Migrate from AutoText to Twenty CRM

AutoText stores tone, formatting, interaction preferences, and shortcut mappings per user in Chrome extension local storage. Twenty CRM does not have a comparable preference layer for writing-style configuration. We document each AutoText preference (tone profile, formatting rules, shortcut assignments) in a written configuration guide that the customer's admin uses to set equivalent behaviors in Twenty or in the email integration tool paired with Twenty. No direct field mapping is possible because the destination schema does not include an equivalent preference object.

AutoText's Chrome extension permissions, enabled/disabled features, and OAuth scope (Google account) are documented from the installed manifest. These are mapped to a written inventory that the customer's admin uses to configure equivalent settings in Twenty or in a connected email tool. The Google OAuth connection must be re-authorized at the destination tool. AutoText extension settings are stored in Chrome local storage with no export format—manual documentation is the only migration path.

AutoText brand voice profiles (tone, terminology, formatting rules) are documented as field values in a configuration inventory. Twenty CRM does not have a native brand voice profile object, but custom text fields or a linked Custom Object can store these values. The customer's admin configures Twenty email templates with the documented brand voice parameters. We preserve the brand profile field values as a written reference that maps to Twenty template content.

AutoText does not store CRM records. Any Contact, Person, or prospect data that the customer maintains elsewhere (spreadsheets, another CRM, Gmail contacts export) migrates to Twenty People via CSV import. We extract from the customer's source, cleanse (dedupe, standardize formats), map to the Twenty People schema (name fields, email, phone, job title, company link, custom fields), and load via Settings → Data Model → Import. Parent records (Companies) must be imported before People so that the company link is satisfied.

Company or Account records sourced from the customer's existing data (spreadsheets, another CRM) migrate to Twenty Companies via CSV. We map company name, domain, industry, address fields, employee count, annual revenue, and any custom fields. Companies are imported first in the sequence so that People imports can resolve the company link. Twenty Companies use the domain field as a natural deduplication key.

Deal or Opportunity records from the customer's existing data migrate to Twenty Opportunities via CSV. We map opportunity name, amount, stage, expected close date, probability, company link, and person link. Opportunities reference both the Company (Account) and the Person (Contact) as foreign keys that must be resolvable at import time. The import sequence is: Companies first, then People, then Opportunities.

Activity records (tasks, notes, meeting summaries) from the customer's existing data migrate to Twenty Tasks and Notes via CSV. Twenty's Task object supports title, body, due date, status, and linked Person/Company. Notes support rich text body and linked Person/Company. We map historical activity data from the customer's source into the appropriate Twenty object, preserving linked Person and Company references where resolvable.

If the customer has Custom Objects in an existing CRM (Projects, Subscriptions, Properties, Vehicles) that they want to replicate in Twenty, we pre-create the destination schema in Twenty (Settings → Data Model → Custom Objects) with all custom fields and lookup relationships, then load data via CSV. Twenty's Custom Object API supports standard CRUD operations on self-hosted and cloud deployments. We document the schema mapping for each Custom Object before any data moves.

AutoText does not expose a public API for suggestion acceptance history. This data is not migratable and we do not attempt to reconstruct it. Users should expect to rebuild any historical writing-quality context at the destination over their first week of use. We note this boundary in the migration scope document delivered to the customer before work begins.

AutoText caches Gmail thread context locally for its own inference. This ephemeral session data evaporates when the extension is uninstalled and has no export path. We do not attempt to migrate thread context caches. The customer's Twenty instance will accumulate fresh activity data from the day of go-live forward. We set this expectation during scoping so that the customer does not anticipate suggestion-quality continuity from AutoText.