Migrate from Trengo to Salesforce Service Cloud

Trengo Conversations map to Salesforce Cases. Each conversation's status (open, pending, resolved, closed) maps to Salesforce Case Status with the customer choosing whether to flatten Trengo's internal notes into Case Comments or keep them as separate internal records. The 7-day rolling window property in Trengo has no Salesforce analog; we migrate conversation metadata including created_at and last_activity timestamps but do not replicate the rolling window behavior since Salesforce Case has no equivalent constraint.

Trengo Messages (inbound, outbound, and internal notes) migrate to Salesforce EmailMessage records for email-channel threads and CaseComment records for internal notes. Message timestamps, sender attribution (agent or customer), and attachment references transfer as ContentDocumentLink attachments. Pagination across large message threads is handled via cursor-based iteration to avoid mid-migration window resets on active conversations.

Trengo Contacts map directly to Salesforce Contacts. Standard fields (name, email, phone, company) migrate 1:1. Custom contact properties require field-mapped destination fields with type conversion for date, boolean, and multi-select picklist types. We validate email format and uniqueness before insert to avoid Salesforce duplicate rules blocking the import.

Trengo Channels (WhatsApp, email, Instagram, Facebook, live chat, voice, SMS) map to Salesforce channel configurations. Email channels map to Email-to-Case; Instagram and Facebook map to Social Customer Service; voice and WhatsApp require separate Salesforce licensing (Voice, Messaging, or Amazon Connect integration) and migrate as metadata indicating which channels were active rather than as live routing configurations. The customer configures channel routing in Salesforce post-migration.

Trengo Teams and their member assignments map to Salesforce Queues. Each Trengo team becomes a Queue with Group members populated from the Trengo team member list. Routing rules that assigned conversations to teams based on channel or inbox are exported as structured configuration JSON; the customer's Salesforce admin rebuilds these as Omni-Channel Routing Configurations or Assignment Rules post-migration since Trengo's rule model and Salesforce's routing model are not directly compatible.

Trengo User profiles (name, email, role, active/inactive status) map to Salesforce Users. We resolve by email match. Inactive Trengo agents map to Salesforce Users with IsActive = false so that conversation ownership history is preserved even if the agent has departed. Any Trengo User without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import.

Trengo Knowledge Base articles with body content, categories, and publication status migrate to Salesforce Knowledge ArticleVersion records. Article-category hierarchies map to Salesforce data categories. Widget associations on articles (embedding articles in the Trengo help center widget) are exported as configuration notes; the customer's admin rebuilds article-to-portal associations in Lightning community builder post-migration. Salesforce Knowledge requires a separate SKU (Knowledge Add-On or Unlimited/Performance edition) which we confirm during scoping.

Tags applied to Trengo Conversations migrate to Salesforce Case as a multi-select picklist custom field or as Case Tags depending on the customer's preference. Tags applied to Contacts migrate to Salesforce Contact tags or a custom multi-select field. Tag naming collision is resolved with a prefix convention during scoping to avoid conflicts with existing Salesforce tag namespaces.

Trengo aggregated reporting data (CSAT scores, response times, channel volumes) is exportable as CSV and migrates as a reference dataset linked to the destination Cases rather than as live Salesforce Reports. The customer rebuilds dashboards and report criteria in Salesforce's report builder because report definitions are configuration rather than data. SLA thresholds and performance benchmarks from Trengo are itemized as setup notes for the customer's admin to reconfigure in Salesforce Entitlements.

Trengo automation workflow definitions (triggers, conditions, actions) are exported as structured JSON where the API exposes them. Salesforce Flow and Trengo Workflows are different automation models; we do not migrate them as code. We deliver a written inventory of every active Trengo workflow with its trigger, conditions, actions, and recommended Salesforce Flow equivalent for the customer's admin or a Salesforce partner to rebuild post-migration.