Migrate from Textline to Salesforce Sales Cloud

Textline Contacts with a phone number as the primary identifier map to Salesforce Contact. We use the phone number as the dedupe key during import and resolve it against existing Salesforce Contacts. Contacts without an email address (phone-only in Textline) are imported as Contacts rather than Leads because Salesforce Lead requires an email or phone, and phone-only is valid. Tags applied to the Contact migrate to a custom multi-select picklist field on Contact with the original tag taxonomy preserved.

Each Textline Conversation maps to one or more Salesforce Activity records. Inbound messages become Tasks with TaskSubtype=Call (or Email depending on configuration), outbound messages become Tasks with the direction preserved in a custom field. MMS messages become Tasks with the attachment URL stored and the file re-downloaded and uploaded as a ContentDocument linked via ContentDocumentLink to the Contact. We use the Bulk API 2.0 for large conversation volumes with chunking and backoff on rate-limit responses.

Textline's multi-number setup using Departments maps to a custom phone field on Contact (e.g., texting_number__c) storing the Textline phone number that initiated or received the conversation. This preserves the multi-number context without a direct Salesforce equivalent. If departments represent team groupings, we map them to Salesforce Queues or a custom department field.

Textline Agents map to Salesforce Users by email match. The agent's name and department assignment migrate to the User record and a custom department field. Permissions and Custom Roles from Textline do not have a direct Salesforce equivalent and require manual rebuild in Salesforce Profiles and Permission Sets post-migration.

Textline canned reply templates migrate as Salesforce Email Templates. We export the template body and shortcut codes, then recreate them in Salesforce as Visualforce or Lightning Email Templates. Merge field syntax differs between platforms and requires manual adjustment for each template before activation.

MMS attachments within Textline conversations are stored as URLs in the conversation export. We re-download each accessible attachment and re-upload it to Salesforce as a ContentVersion record, linked to the parent Contact via ContentDocumentLink. This media-handling step is not required for text-only conversations and adds time to the attachment migration phase.

Tags applied to Textline Contacts migrate as values in a custom multi-select picklist field on the Contact object (e.g., textline_tags__c). Tag taxonomy and naming conventions are preserved as-is. If the number of unique tags exceeds Salesforce's picklist value limit, we split into multiple custom fields or use a Salesforce Data Category approach.

Textline Announcements (bulk outbound messages) map to Salesforce Campaign records, with the announcement content as the Campaign Description and the associated contact list as CampaignMembers. We export the announcement body, send date, and list membership during scoping. If announcements were one-time broadcasts, we document them for manual Campaign setup in Salesforce rather than bulk-importing them.

Textline custom address book fields on Standard and Pro plans migrate to Salesforce custom fields on Contact with type mapping: Textline text fields become Text fields, date fields become Date fields, and dropdown fields become Picklist fields. Field-level security is set during schema design. On Essentials accounts, custom fields do not exist and we fall back to standard Contact fields (name, phone, email, notes).

Textline Automations (keyword triggers, time-based triggers, contact-action triggers) are documented with their trigger conditions and actions in a written inventory delivered at migration close. Automations cannot be migrated programmatically because Salesforce Flow uses a different trigger model. The customer's admin or a Salesforce partner rebuilds them in Flow post-migration.

Textline Routes (inbound message routing rules) are not exposed via the public API and cannot be migrated programmatically. We document the routing logic during discovery: which phone number routes to which department, which agent or queue receives the assignment. This is delivered as a written routing map for manual rebuild in Salesforce Case Assignment Rules or Flow.

Textline built-in metrics (NPS, CSAT, agent performance statistics) are aggregated reporting data with no direct migration target in Salesforce. We export the raw survey response data if accessible via API so the customer can recreate dashboards in Salesforce Reports or an external BI tool. This is documented as a reporting rebuild item in the handoff package.