Migrate from Aidoo Mobile to Salesforce Sales Cloud

Aidoo Mobile work-order statuses have no native Salesforce equivalent

Aidoo Mobile uses field-service-specific work-order statuses such as Assigned, In Progress, On Hold, and Completed. Salesforce's native Case.Status pick-list uses New, Working, Escalated, and Closed — these values do not align with an FSM lifecycle. FlitStack AI creates a custom AM_Status__c pick-list on the Case object and builds a value-mapping table that translates each Aidoo Mobile status to its Salesforce custom field counterpart. The standard Case.Status field is available for Salesforce-native routing and escalation logic independent of the migrated Aidoo values. Teams must decide whether to display the custom AM_Status__c field on the case page layout or use it purely for reporting continuity.

Technician records resolve to text fields, not Salesforce User lookups

Aidoo Mobile stores technician information as named entities linked to work orders. Salesforce Sales Cloud has no native technician object — Service Cloud uses Skills, Service Resources, and Shifts with Field Service Lightning, but those are not available in a base Sales Cloud org. FlitStack AI migrates the technician name as Technician_Name__c on each Case and the route assignment as Route_Assignment__c. If technicians should become Salesforce Users (enabling Salesforce-native assignment), your team must create Salesforce User records for each technician before migration and FlitStack AI will match by email. Unmatched technicians receive a fallback owner assignment and are surfaced in the pre-migration report.

Aidoo Mobile custom fields multiply schema complexity in Salesforce

Aidoo Mobile supports custom fields on companies, contacts, work orders, and assets. Each Aidoo Mobile custom field maps to a Salesforce custom field using the __c API name suffix. If Aidoo Mobile custom fields use pick-list types, Salesforce custom pick-lists require the same value-by-value mapping approach as the native status and priority fields. We deliver a custom-field creation manifest as part of the pre-migration schema plan, but Salesforce field limits (max 500 custom fields per object) must be respected. Teams with more than 100 custom fields on a single Aidoo Mobile object should audit which fields are actively used before migration to avoid hitting Salesforce limits.

Aidoo Mobile address data requires field splitting before Salesforce load

Aidoo Mobile stores location data as a single unstructured text field per work order or account. Salesforce Account and Case use structured address components (Street, City, State, PostalCode, Country). FlitStack AI splits the Aidoo Mobile location string using comma and whitespace delimiters, with manual QA review for records where the address structure is ambiguous. Inconsistent address formats (abbreviations, missing city or state) are flagged in the sample migration report. Teams should review the address-splitting logic on a sample of 50–100 records before the full migration commits.

Aidoo Mobile workflows, routing rules, and scheduling automations do not migrate

Aidoo Mobile stores routing logic, technician dispatch rules, and scheduling automations as platform-specific configurations. These are not stored as data records and cannot be extracted via API. Salesforce Field Service or Salesforce Flow must be used to rebuild this logic. FlitStack AI can export the Aidoo Mobile workflow definitions as a text reference document your Salesforce admin or implementation partner can use to reconstruct routing and dispatch logic in Salesforce Field Service Lightning. This is a manual rebuild effort and should be scoped separately from the data migration budget.