Migrate from OpenText Service Request Center (SRC) to Salesforce Service Cloud

SRC Service Requests map to Salesforce Case with a dedicated Record Type that separates them from Incident cases. Request category, priority, status, and assigned support group migrate to Case Status, Priority, and OwnerId. The SRC request_id becomes a custom field src_request_id__c for audit traceability. We resolve the assigned support group to a Salesforce Queue or User during migration, using email or group name as the dedupe key.

SRC Incidents track IT infrastructure disruptions separate from Service Requests. We map to a distinct Case Record Type (Incident) so that Impact and Urgency fields from SRC map to custom Incident-specific fields while the core Case Status and SLA milestone remain shared with Service Request cases. This keeps both record types under a single Entitlements framework in Salesforce.

SRC Customer records (external requesters distinct from internal Users) map to Salesforce Contact. We use email address as the dedupe key and import display name, department, phone, and any custom fields. Contact records are created before Case records so that the Case ContactId lookup is satisfied at insert time. If SRC customers overlap with SRC users (agents filing requests for themselves), we deduplicate against the User migration.

SRC internal users (agents and administrators) map to Salesforce User records. We resolve by email address. Display name, department, title, and manager hierarchy migrate to equivalent Salesforce fields. Active/inactive status is preserved. Passwords cannot migrate and require the customer's Salesforce admin to set initial credentials or trigger password reset emails post-migration.

SRC support groups and team assignments that define ticket routing and agent ownership map to Salesforce Queues (public groups used for case assignment) or private Groups. We export group membership and email routing aliases during discovery and recreate them in Salesforce during the schema phase. Routing rules in SRC that assign tickets by category or priority map to Salesforce Omni-Channel Routing configurations post-migration.

SRC KB Articles migrate to Salesforce Knowledge with HTML sanitization applied during the transform phase. Embedded images and tables that reference OpenText Content Suite assets are extracted and re-uploaded as Salesforce Files linked to the article. Article-to-ticket associations are preserved by linking related Cases to the migrated article via CaseArticle. Article categories from SRC map to Salesforce Lightning Knowledge data categories, though the customer may need to restructure the category hierarchy during the catalog rebuild phase.

Attachments linked to Service Requests and Incidents migrate as Salesforce ContentVersion records (the file binary) linked via ContentDocumentLink to the parent Case. The primary risk during SRC migration is external Content Suite repository references: if an attachment record points to a URL outside the SRC database rather than a file stored inline, we retrieve the file during discovery and import it inline. Any unresolved external references are documented in a broken-links report for manual resolution.

SRC custom fields on Service Requests and Incidents are audited during discovery, including field data type, picklist values, and validation rules. We pre-create equivalent custom fields on the Case object in Salesforce before migration begins. Data type mismatches (for example, a SRC date-time field stored as a text string) are resolved during the transform step. Validation rules from SRC are documented in a custom-field inventory and recreated manually in Salesforce Setup by the customer's admin team after migration.

SRC SLA definitions define response and resolution targets tied to priority level and service category. We export SLA configurations during discovery and map them to Salesforce Entitlement Processes (a container for SLA milestones) and Milestones (individual response and resolution time targets). Because SRC SLA calendars are custom-defined per deployment and differ between service categories, we audit each calendar during discovery and map it to Salesforce Business Hours, flagging any mismatches between SRC business-hour definitions and the destination Business Hours schedule. Closed cases without active SLA tracking migrate with the SLA history preserved as custom fields for reporting.

SRC workflow definitions are tightly coupled to the platform's internal process engine and are not exportable in a portable format. We do not migrate workflows as code. We deliver a written inventory of every active SRC workflow with its trigger conditions, actions, assignment rules, and notification logic, mapped to a recommended Salesforce Flow type (record-triggered, scheduled, or screen Flow) or Omni-Channel configuration. The customer's admin team rebuilds workflows post-migration. We provide the inventory and design guidance but do not build the Flow inside the migration scope.

SRC service catalog items and request offerings are not migrated as structured records. We extract catalog item metadata (name, description, category, available to groups) during discovery and deliver it as a catalog reconstruction guide in CSV format. The customer's admin rebuilds catalog entries using Salesforce's Flow-based catalog builder or Experience Cloud, depending on the desired portal experience. Approval workflows tied to catalog items are included in the workflow inventory deliverable.

SRC entitlements tied to customer contracts and support tier levels map to Salesforce Entitlement records linked to Contact and Account. Entitlement name, start and end dates, and type migrate directly. If the destination org uses Salesforce Entitlements Management, we create Entitlement records before Cases so that Cases can reference them via the EntitlementId field, enabling automatic SLA milestone creation on case creation.