Migrate from Neoforce to Salesforce Service Cloud

Neoforce Tickets map to Salesforce Cases with status, priority, category, assignee, and all custom fields transferred. Neoforce status values (Open, Pending, Resolved, Closed) translate to Salesforce Status values that we configure as picklist options during Case Record Type setup. Neoforce category maps to a custom picklist or Record Type depending on whether the customer uses multi-category routing. Comments on tickets migrate as EmailMessage records attached to the Case, preserving the original timestamp and author reference. Attachment binary references from Neoforce become Salesforce ContentDocument records linked via ContentDocumentLink to the parent Case.

Neoforce Company records map directly to Salesforce Account. The company name becomes Account Name, physical address fields map to standard Address composite fields, and any custom Company fields map to custom Account fields. Company records are inserted before Cases so that the AccountId lookup on Case is satisfied at the moment of import. We use the Company domain or name as the dedupe key to prevent duplicate Accounts during import.

Neoforce Agent accounts with roles and permissions map to Salesforce User records. We map by email address as the primary key. Neoforce role names and permission levels are preserved as custom text fields on the destination User object (neoforce_role__c, neoforce_permission_level__c) so the customer's admin can reconstruct permission sets and profiles post-migration. Active/inactive status maps directly. Password credentials do not transfer and must be reset by the customer post-provisioning.

Neoforce Light Accounts (free end-customer portal accounts) may lack an email address or full contact details in some export scenarios. We flag every Light Account record during scoping, separate those with complete contact fields from those without, and apply a configurable email-placeholder strategy (e.g., lightaccount_[id]@placeholder.local) to prevent orphaned Case-contact relationships. Complete Light Account records migrate as Salesforce Contact records linked to the relevant Account. The customer chooses whether to provision these as Customer Portal users in Experience Cloud.

Neoforce Asset records (hardware and software tracked in the asset management module) map to Salesforce Asset with name, serial number, status, and custom fields preserved. The link from Asset to Company maps to Asset.AccountId referencing the corresponding Account record created from the Neoforce Company migration. Asset relationship to Contracts is preserved via the Salesforce Asset's linked ContractId where available.

Neoforce Contract records map to Salesforce Contract with contract terms, renewal dates, and custom fields. Renewal date semantics transfer to Contract.EndDate and the contract status maps to Salesforce Contract Status values. The customer configures the contract activation date and renewal reminders in Salesforce after migration. Contract-to-Asset and Contract-to-Account links are resolved via lookup fields pointing to the migrated Asset and Account records.

Neoforce SLA definitions (response time, resolution time, escalation thresholds, and chain-of-escalation rules) are stored as configuration objects that do not transfer as data records. We extract and document every SLA tier with its exact response and resolution time thresholds, the escalation trigger percentages, and the chain-of-escalation agent group references. The customer uses this documented blueprint to configure Salesforce Entitlements (entitlement name, service contracts, business hours) and Milestones (response and resolution time targets) in the destination org. Escalation chain logic is destination-specific and must be rebuilt as Salesforce Flow or Assignment Rules.

Neoforce v26.02 wiki article content and metadata export via the platform's PDF export and API access where available. We extract article body text, category assignments, and publish status, then map them to Salesforce Knowledge article types that the customer configures before migration (Data Category groups and categories must be provisioned in the destination org). The article publish date, author, and view count are preserved as custom fields on the Salesforce Knowledge article. Salesforce Knowledge must be enabled in the destination org; it is not active by default on all Service Cloud editions.

Tags applied to Tickets, Assets, and Companies in Neoforce export as a flat tag vocabulary per record. We preserve the complete tag array and apply the customer's chosen strategy during scoping: multi-select picklist on the Case object for operational tag use, or Salesforce Topics with TopicAssignment records for taxonomy-driven classification. The customer decides during scoping which strategy applies per object.

Neoforce custom fields on Tickets (name, field type, required flag, picklist options) are exported alongside field values. We provision matching custom fields on the Salesforce Case object using the same API name convention with a __c suffix. Field types are mapped to Salesforce equivalents: Neoforce text to Text(255), Neoforce number to Number, Neoforce date to Date, Neoforce dropdown to Picklist. Required flags map to field-level required configuration on the Case layout.