Migrate from Novo Work Order to Salesforce Sales Cloud

Novo Work Order maps directly to Salesforce Case. The CaseNumber in Salesforce receives the Novo work order ID for traceability. Status values map via value-mapping table (Novo Open → Salesforce New, Novo In Progress → In Progress, Novo On Hold → Waiting on Customer, Novo Complete → Closed, Novo Cancelled → Cancelled). Priority maps 1:1.

If Novo work orders have custom fields that don't fit Salesforce Case's standard schema (e.g., specific municipal permit fields), FlitStack creates a Work_Order__c custom object with a master-detail link to Case. This keeps native Case features (email-to-case, Web-to-Case, Case Team) while storing Novo-specific data in custom fields.

Novo assets map 1:1 to Salesforce Asset. The Asset's Name, SerialNumber, InstallDate, Status, and AccountId (linked to the Account representing the asset's location/owner) transfer directly. Novo's asset hierarchy (parent/child equipment) maps to Salesforce's ParentAssetId lookup. If a Novo asset references a location that does not yet exist as a Salesforce Account, FlitStack creates the Account on the fly, linking the asset to ensure continuity.

Novo's Preventive Maintenance records have schedule rules, frequency, and last-run dates. Salesforce has no native PM object — FlitStack creates a PM_Schedule__c custom object with master-detail to Asset. PM_Schedule__c stores frequency, next_due_date, last_completed_date, and a link to the related Case created when the PM runs.

Novo Departments route work orders to teams. Salesforce Queues handle Case assignment for groups. FlitStack creates a Queue per Novo Department and a custom Department__c pick-list field on Case for reporting. Technicians resolve to Salesforce Users by email match — unmatched technicians flagged for admin review before migration.

Novo locations (addresses, facilities, infrastructure) map to Salesforce Account. Municipalities typically use Account for external entities (vendors, partner agencies) and may use a custom Location__c object for internal facilities — FlitStack recommends Account for external-facing locations and creates Location__c for internal infrastructure when the inventory is large.

Novo records multiple labor entries per work order (technician, hours, date). Salesforce Case has no native labor sub-object. FlitStack merges these into Total_Labor_Hours__c (sum), Labor_Cost__c (sum), and a custom Work_Order_Labor__c junction object if individual line-item audit is required. When labor entries include overtime rates or varying wage codes, FlitStack stores the overtime hours in a separate Overtime_Hours__c field and calculates additional cost in Overtime_Cost__c, ensuring accurate labor budgeting.

Novo tracks parts used per work order with quantity and cost. FlitStack maps parts to Product2 (if an inventory catalog exists) and creates a custom Parts_JSON__c field on Case storing the array of parts consumed. Individual part line items can be preserved in a custom Work_Order_Parts__c object for full audit history.

Novo file attachments and inspection photos re-upload to Salesforce Files and link to the related Case or Asset record via ContentDocumentLink. Salesforce's 25MB per-file limit applies — large photos are compressed before upload. Inline images in work order notes are extracted and rehosted.

Novo technicians resolve to Salesforce Users by email match. If a Novo technician has no matching Salesforce User, their records are assigned to a fallback OwnerId (typically the admin's user) and flagged in the pre-migration report for the customer to create or link accounts before go-live.

Novo work order comments and internal notes map to Salesforce CaseComment. Original timestamps and the commenting technician's name (resolved to Salesforce User) are preserved. Rich-text formatting in Novo notes is converted to plain text with line breaks preserved in CaseComment.Body.

Novo custom properties on work orders (e.g., permit_number, inspection_result, funding_source) require Salesforce custom fields. FlitStack creates these as pick-list, text, number, or date fields depending on the source type. Field-level API name uses the __c suffix. Any invalid Salesforce field names (spaces, special characters) are normalized before migration.