Migrate from Wolken Service Desk to Salesforce Service Cloud

Wolken Requests map directly to Salesforce Cases. The Request status (open, in-progress, resolved, closed) maps to Salesforce Case Status. Wolken sub-status values migrate to a custom Case sub-status picklist field that the customer's admin configures on the Case object. Priority, category, assigned agent, requester, and all standard fields map 1:1. The Request created date and last-modified date migrate as Salesforce Case CreatedDate and LastModifiedDate. Request custom fields defined via the Request Metadata API map to pre-created Salesforce Case custom fields of equivalent type.

Wolken Customer records map to Salesforce Contacts attached to Accounts. The customer's name and contact information (email, phone, address) map to Contact fields. If Wolken Customers include company-level data, we map the parent organization to a Salesforce Account and link the Contact to it via AccountId. Email address serves as the dedupe key during import. Wolken Customer records without a resolvable company name import as Contacts with no Account association pending admin review.

Wolken Agent profiles (name, role, team assignment, availability settings) map to Salesforce Users. We resolve Agents by email match against the destination Salesforce org's User table. Wolken team structures and role hierarchies require manual mapping to Salesforce Profiles, Roles, and Queues because Salesforce's security and routing model differs structurally from Wolken's team-based assignment. Agents without a matching Salesforce User go to a reconciliation queue for the customer's admin to provision.

Wolken SLA Policies define response and resolution time windows per priority or category. We export SLA Policy definitions and map them to Salesforce Entitlement Processes (for milestone timing) and Entitlement records (for case-level association). The Entitlement links to a Service Contract or Asset if that data is present in Wolken. Entitlements in Salesforce have entry criteria that must be designed to match Wolken's SLA assignment logic, which the customer's admin reviews and approves during scoping.

Wolken Knowledge Base articles (title, body, category, publication status, permissions) map to Salesforce Knowledge articles. Article categories map to Salesforce Knowledge data categories. Publication status (draft, published, archived) migrates to Salesforce article ActiveVersion status. We preserve the article body as rich text with embedded media. Customer-facing permissions migrate as Salesforce Knowledge article visibility settings. Wolken KB category hierarchy requires mapping to Salesforce data category groups during schema design.

Wolken Forms act as structured intake channels that route submissions to specific Request types. Form definitions and field structures export as configuration records. The routing logic tied to Forms does not migrate because Salesforce routing is handled by Omni-Channel Routing and Flow, not form-level rules. We deliver a written form inventory documenting the source form fields, routing targets, and recommended Salesforce Web-to-Case or Omni-Channel setup for the customer's admin to rebuild.

Wolken stores attachments as references linked to individual Requests. There is no bulk blob-export endpoint, so we resolve each attachment URL individually during migration. Large attachment volumes significantly extend the export phase. Resolved binary files upload to Salesforce as ContentDocument records linked via ContentDocumentLink to the parent Case. We pre-scan all attachment references during scoping and estimate per-file resolution time before migration begins.

The Request Metadata API exposes dynamic custom fields defined per Request type. We export the full metadata schema including field names, data types, and picklist values. Each custom field requires a pre-created Salesforce Case custom field of equivalent type before import. Picklist values map directly; free-text fields map to Salesforce text areas; numeric fields map to number fields with appropriate precision. The customer approves the custom field schema in Salesforce before we proceed with data import.

Wolken Customer records that represent organizations (not individual contacts) map to Salesforce Account records. Customer name becomes Account Name, website becomes Account Website, and industry or type fields map to Salesforce Account Type or Industry. If the same Wolken Customer record contains both company and individual contact data, we split it into an Account record (for the company) and a Contact record (for the individual) linked by AccountId.

If Wolken Requests reference assets or products (common in ITSM and field service contexts), we map these to Salesforce Asset records linked to the Account and Case. Asset Name, Product2 reference, SerialNumber, and Status migrate from Wolken's asset or product reference fields. The customer must confirm whether Wolken maintains a separate asset store during scoping so we can design the appropriate Account-Asset-Case relationship structure.