Migrate from Sunrise HR Case Management to Salesforce Service Cloud

Sunrise HR Cases are the primary migration object and map directly to Salesforce Case. We extract case status, priority, category, assignee, created and updated timestamps, and the linked employee as a Contact lookup. Case audit trail history migrates as Salesforce CaseComment records preserving the original timestamp, author, and body text. We resolve the employee-to-Contact lookup using the Sunrise employee identifier from the integrated Infor HCM or connected HRIS before case import begins.

Sunrise HR Queries are lightweight request objects tracked alongside Cases. We extract query text, submitter, assigned handler, and resolution status. Each Query migrates as a Salesforce Case record with a custom field Query_Type__c set to 'Query' to distinguish it from primary Cases. The Query's parent Case relationship is resolved through a custom Parent_Case__c lookup field linking the Query to the originating HR Case by Sunrise case identifier.

Sunrise HR Requests represent structured service requests such as absence approvals, equipment requests, and onboarding steps. We map request type, custom fields, approval chain, and current stage to a Salesforce Case using a custom record type HR_Request__c. Approval stage values migrate to Case custom fields, and the approval chain migrates as a sequential series of Task records representing each approval step with the approver name and status.

Sunrise Employees are referenced from the integrated HRIS (Infor HCM or a connected HRIS) and linked to cases as the subject employee. We map the employee identifier, first name, last name, email, and department to Salesforce Contact. Employees who need Salesforce Experience Cloud portal access map to Contact with Account linkage; all others map as standalone Contact records. The Sunrise employee identifier is preserved in a custom field Sunrise_Employee_ID__c for reconciliation if the HRIS changes post-migration.

Agents in Sunrise HR Case Management are the HR staff who own and resolve cases. We extract agent name, role, team assignment, and workload flags. Agents map to Salesforce User records by email match. Role and team information from Sunrise is stored as User fields and Queue membership records. Sunrise team structures frequently differ from Salesforce org hierarchies, and we flag team mapping discrepancies during discovery for manual reconciliation before the agent migration phase.

SLA definitions in Sunrise are tied to case categories and stored in the Infor OS configuration layer. We export SLA names, target resolution times, and breach timestamps as flat reference data during discovery. The active SLA rules (which SLA applies to which case type and what happens on breach) require manual re-creation in Salesforce as Entitlement Processes and Milestones in Setup. We deliver a mapping document that pairs each Sunrise SLA category with the recommended Salesforce Entitlement Process structure for the customer to implement post-migration.

Automatic escalation rules that trigger alerts or reassignments based on SLA breach or case inactivity are stored as Infor workflow engine configuration, not as data records in the Sunrise database. These are not exportable. We document every visible escalation rule during discovery and deliver a written inventory that maps each Sunrise escalation trigger to a Salesforce Flow record-triggered flow or Assignment Rule. Escalation rule rebuild is a post-migration admin task; we do not implement Flow configurations as part of the standard migration scope.

Documents attached to Sunrise HR Cases—including policies, evidence files, and correspondence—are extracted as binary blobs from the Infor REST API. We download each file, map it to the corresponding Salesforce Case record, and re-attach it as a ContentDocument with a ContentDocumentLink to the Case. Original filenames, MIME types, and upload timestamps are preserved. Large attachment sets (over 10,000 files) use chunked download batches with checksum validation to ensure completeness.

Case categories and tags from Sunrise export as flat label lists without hierarchy. We map these to a Salesforce custom multi-select picklist field Case_Category__c on the Case object. Where duplicate categories exist across Sunrise and Salesforce naming conventions, we merge the labels and flag unresolvable conflicts for the customer's admin to resolve post-migration. The customer chooses during scoping whether to use multi-select picklist or Salesforce Topics as the target taxonomy.

Historical SLA breach events in Sunrise are stored as audit entries on each case record. We export breach timestamps, the breached SLA name, and resolution time delta as read-only custom fields on the Salesforce Case (for example, SLA_Breach_Date__c, SLA_Breached_Name__c, SLA_Resolution_Delta_Hours__c). Salesforce's native Entitlement Process recalculates SLA status after migration; these custom fields preserve the historical compliance record for audit and reporting purposes and are set to read-only on all migrated cases.

Power BI dashboards linked to Sunrise's Infor OS reporting layer cannot be exported as portable objects. We extract the underlying case metrics, category volumes, resolution times, and SLA compliance data as a structured data export during discovery. The customer's admin uses this extract to rebuild reports and dashboards in Salesforce's native Reports and Analytics module post-migration. This work is outside the data migration scope and is delivered as a documentation artifact.

Automated task assignments, case notifications, and routing rules in Sunrise live in the Infor workflow engine and are not accessible as exportable data. We document the visible automation logic during discovery—including trigger conditions, action sequences, and notification recipients—and deliver a written automation inventory with recommended Salesforce Flow equivalents. Flow rebuild is a post-migration engagement scoped separately; we do not implement Salesforce Flow configurations as part of the standard migration.

Sunrise HR Cases may include custom fields beyond the standard status, priority, and category set. During scoping we inventory all visible custom fields, classify each by Salesforce field type (text, number, date, picklist, checkbox), and pre-create matching custom fields on the Salesforce Case object before migration begins. Sunrise picklist values are mapped to Salesforce picklist values with unsupported values flagged for manual cleanup.

Sunrise case audit trails contain the full chronological history of case changes, status transitions, and handler notes. We export this history as a sequence of CaseComment records ordered by the original Sunrise timestamp. Each CaseComment carries the author (resolved to Salesforce User or Contact by email), body text, and created date matching the original event. The final CaseComment on each migrated case is marked with the current status to preserve the resolved state in the audit trail.

If the customer is also migrating away from Infor HCM to a different HRIS (such as Workday, BambooHR, or SAP SuccessFactors), the employee-to-case linkage requires re-establishment after migration. We deliver a Sunrise_Employee_ID__c cross-reference table during migration so that the customer's admin can re-link cases to employee records in the new HRIS without a full re-import. This is a post-migration data fix step, not a re-migration.

Sunrise stores priority as a case attribute tied to SLA tier. We map priority values to a Salesforce custom picklist Priority_Tier__c on Case, preserving the original Sunrise label. Priority affects SLA entitlement selection in Salesforce, so the mapping document explicitly pairs each Sunrise priority level with the target Entitlement Process and Milestone that should apply post-migration.

Sunrise agent workload flags indicate whether a handler is at capacity or overloaded. These flags migrate as read-only custom fields on the Case (Handler_Workload__c) sourced from Sunrise agent workload data at the time of migration. Active workload balancing after migration is handled by Salesforce Omni-Channel and Capacity Model, not by migrating historical workload snapshots.

Organisations procuring Sunrise HR Case Management via the UK Government G-Cloud framework may have contractual data residency requirements. We confirm the applicable G-Cloud service schedule obligations during discovery and set the Salesforce org region accordingly. Salesforce Data Residency (available on Unlimited and Performance tiers) or a Salesforce region-locked org deployment satisfies most G-Cloud data residency obligations, though the customer should verify against their specific G-Cloud service schedule.