Migrate from Tender Support to Salesforce Service Cloud

Tender Support Tickets map to Salesforce Service Cloud Case records. Subject maps to Case Subject, Ticket body or first message to Description, Ticket status (open/closed/pending) to Case Status, and priority to Case Priority. Full message thread migrates as CaseComments ordered by timestamp. Ticket created_at becomes Case.CreatedDate. We set the Case origin to match Tender Support's channel metadata if present in the export, defaulting to Email if the field is absent.

Tender Support Customer records map to Salesforce Contact. Email address is the dedupe key and becomes Contact.Email. First and last name map to the corresponding Contact fields. If a Customer has multiple linked Tickets, we create one Contact and attach all related Cases via ContactId on Case. Any Customer metadata fields (company name, phone) map to Contact.Phone and Contact.AccountId via Account lookup if the customer provides a company name export.

Tender Support Agent accounts (admin or regular role) map to Salesforce User records by email match. Agents who are not yet provisioned in Salesforce at migration time are placed in a reconciliation queue. We recommend provisioning the Salesforce Users before the production migration phase begins so that the OwnerId field on Case can be resolved at insert time. Agents marked as inactive in Tender Support before cutover are migrated as inactive Salesforce Users to preserve assignment history.

Tender Support uses a flat, single-level label vocabulary with no hierarchy. Sites with many labels often have overlapping or inconsistently applied tags. We deduplicate and normalise the label set during the mapping phase, grouping semantically similar labels into a single destination Tag (for Salesforce's Topics-and-TopicsAssignment model) or Case Category. We document every label-to-tag decision in a written mapping table so the customer's admin can audit and adjust after go-live. Labels with fewer than five associated Tickets are consolidated into an 'Other' tag to avoid tag sprawl.

Tender Support attachment URLs point to files stored in Tender Support's cloud storage. We download each attachment to local storage during migration, rename the file to preserve the original filename, and re-upload it to Salesforce as a ContentVersion linked to the parent Case via ContentDocumentLink. Salesforce's 25 MB per-file limit and 2 GB per-org storage are verified before migration begins. If any attachment exceeds Salesforce limits, we flag it for the customer's admin to store externally and link by URL instead.

Tender Support internal notes require special handling because some export formats render them as regular message rows without a visibility flag. We inspect the message_type or equivalent column in the raw export to identify internal notes by content pattern (often prefixed with '[internal]' or matching a known note-author) and apply Salesforce's CaseComment.IsPublished = false flag during import. If the export omits this signal entirely, we flag those records for manual review before committing the import and document the decision in the reconciliation report.

Tender Support supports custom fields defined by the admin with varied field types (text, number, date, dropdown). We discover all active custom fields during discovery, map each to a typed Salesforce Case field, and pre-create any custom fields in Salesforce before migration. Text fields map to Textarea(255) or Long Text Area; number fields to Number; date fields to Date. If the destination Salesforce edition has a Field Level Security model, we grant read/write access to the migration user before insert.

Tender Support ticket statuses (open, pending, resolved, closed) map to Salesforce Case Status values in the active Salesforce Business Process. We configure the Case Status picklist values to match the source statuses during the pre-migration schema phase, preserving any custom statuses the customer has added in Tender Support. Closed ticket timestamps become the Case.ClosedDate for reporting purposes.

Tender Support does not have a native SLA object or first-response/resolution-time tracking feature. No SLA data exists in the export to migrate. If the destination Salesforce org includes Service Cloud with Entitlements, the customer's admin configures SLA Policies, Entitlement Processes, and Milestone definitions post-migration. We provide a written SLA requirements document (first-response time, resolution time, business hours, escalation rules) based on the customer's Tender Support support-tier data as a configuration guide for their Salesforce admin.

Tender Support does not expose any workflow automation engine via its API. Any rules-based ticket routing, auto-assignment, or triggered actions configured in Tender Support are not present in the data export and cannot be migrated. We do not rebuild workflows as Salesforce Flow inside the migration scope. We deliver a written inventory of every observed routing or assignment pattern in Tender Support with a recommended Salesforce Flow equivalent (e.g., Omni-Channel routing, Assignment Rules, or record-triggered Flow) so the customer's admin or a Salesforce partner can rebuild them post-migration.