Migrate from Stames to Salesforce Service Cloud

Stames Tickets map directly to Salesforce Case records as the primary unit of work. The Stames ticket subject and description map to Case Subject and Description fields. Status, priority, and assignment metadata map to Case Status, Priority, and OwnerId respectively. Any Stames custom fields on the Ticket object map to custom fields on the Case object (__c API name). We configure Case Record Types and Status picklist values in Salesforce to match the Stames ticket pipeline stages before migration.

Stames Customer records contain contact details and organizational metadata. We split Stames Customers into Salesforce Contact (for the individual) and Account (for the organization) records. If the Stames Customer includes a company name, we create or match an Account record first, then link the Contact to it via AccountId. If no company name exists, we use the Customer name as the Account name and create a personal Account. We resolve the Contact.AccountId lookup before inserting the Contact record so that no orphaned Contact records are created during migration.

Stames Conversation messages attached to a Ticket map to Salesforce EmailMessage records linked to the Case. Each message in the conversation becomes a separate EmailMessage record with the original timestamp, sender (agent or customer), and message body preserved. EmailMessage parentid references the Case Id. For non-email channel messages (WhatsApp, SMS, social), we map the channel source to a custom text field on the EmailMessage and store the message body in the EmailMessage body field, noting the channel origin. Threading order is preserved by setting EmailMessage.IncomingDate to the original Stames timestamp.

Stames captures the originating channel (Facebook, Instagram, WhatsApp, Email, API, Contact Forms) as a field on each Conversation record. Salesforce Service Cloud has native support for Email, Chat, and Messaging channels via separate objects. We map Email channel to the native EmailMessage flow, Chat to LiveAgent Transcript records, and WhatsApp to LiveMessage. For Facebook and Instagram (which Stames supports natively), we store the channel source in a custom text field Stames_Channel_Source__c on the Case record. This ensures channel attribution is preserved and filterable even when no direct Salesforce channel object equivalent exists.

Stames agent accounts with roles and permissions map to Salesforce User records. We resolve agents by email match against the destination Salesforce org's User table. Role and permission metadata from Stames flags any permission gaps where Salesforce's sharing model does not support an equivalent. Agents without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision before record import proceeds. Active status in Stames maps to Active = true in Salesforce.

File attachments on Stames Tickets and Conversations are downloaded during export and re-uploaded to Salesforce as ContentVersion records. Each file creates a ContentDocument record linked to the parent Case via ContentDocumentLink (with LinkedEntityId pointing to the Case Id). We preserve the original filename, MIME type, and file size. Media URL references stored in Stames conversation records are updated to point to the new Salesforce Files location after migration.

Tags applied to Stames Tickets for categorization export as label values and map to a Salesforce custom multi-select picklist field on the Case object (Stames_Tags__c). The customer chooses between a multi-select picklist (suitable for up to 500 distinct tag values) or Salesforce Topics with TopicAssignment records (suitable for larger, cross-object tagging schemas). Tag naming consistency is validated before migration to avoid picklist value conflicts in Salesforce.

Stames stores SLA compliance timers, SMS notification triggers, and email reminder settings as metadata on the Ticket record. We export these as custom fields on the Salesforce Case object (for example, SLA_Due_Date__c, SMS_Notification_Enabled__c, Reminder_Trigger__c). Notification triggers that rely on Stames-built-in automation do not migrate; we document each active notification trigger during discovery as a custom field value and flag it for Salesforce Flow or Apex rebuild post-migration.

Stames self-service portal configurations, including custom forms, portal access controls, branding settings, and self-service-facing content, are not exposed via the Stames API and cannot be migrated automatically. We do not include portal configuration in the migration scope. Customers must manually recreate portal settings in Salesforce Experience Cloud or Customer Portal post-migration. We communicate this clearly during discovery and note that portal parity is not achievable through automated migration.

If Stames retains a ticket status change history log (ticket state transitions with timestamps), we map this to Salesforce CaseHistory (the standard audit trail for Case Status changes). If the source records contain intermediate status values not present in the destination Case Status picklist, we extend the picklist during schema design to accommodate all historical values. Status change timestamps are preserved as CaseHistory CreatedDate.

Any Stames custom fields defined at the Ticket level migrate to custom fields on the Salesforce Case object. We map Stames field data types (text, number, date, dropdown) to the closest Salesforce field type (Text, Number, Date, Picklist). Lookup relationships from Stames custom fields to other Stames objects (for example, a custom field linking a Ticket to a custom object) are resolved by pre-creating the destination custom object in Salesforce, then inserting it before the Case import so that the lookup ID is available at insert time.

If the Stames instance includes customer-defined custom objects (for example, a Warranty or Subscription object linked to Tickets), we migrate these to Salesforce custom objects of matching API name (__c suffix). The destination schema is pre-created before migration, including all custom fields, lookup relationships to Case, Contact, and Account, and any validation rules. We insert custom object records after parent records (Case, Contact, Account) are confirmed in Salesforce to satisfy all foreign-key constraints.