Migrate from OptimoRoute to Microsoft Dynamics 365 Sales

OptimoRoute orders become Opportunities representing individual delivery or service jobs. Address, time window, and priority fields map to custom fields on a routing-specific custom table. The Opportunity Name holds the order reference; estimated delivery time maps to CloseDate as a proxy datetime field.

OptimoRoute driver records (name, email, phone, work hours, cost settings) map directly to Dynamics 365 SystemUser for users who will log into D365 Sales, or to Contact for drivers managed externally. Driver skills and vehicle assignments stored as custom fields on the SystemUser record.

OptimoRoute vehicles (plate, type, capacity, features) have no native D365 equivalent. We create a custom vehicle table (cror_vehicle) in Dataverse with fields for registration, vehicle type pick-list, capacity (weight/volume), and feature flags (refrigeration, loading ramp). This table links to SystemUser records for driver-vehicle assignments.

OptimoRoute routes carry optimization logic, sequence, and driver assignment that has no native D365 counterpart. We create a custom route table (cror_route) capturing route name, date, assigned driver (lookup to SystemUser), and status. Individual route stops (ordered delivery points) land as Opportunity records linked to the route, preserving the sequence number as a custom integer field.

OptimoRoute stores full address strings on orders: address_line_1, address_line_2, city, state, postal_code, country. We parse these into Dynamics 365 Account address1 fields (address1_line1, address1_city, address1_stateorprovince, address1_postalcode, address1_country). A separate address2 block holds any secondary delivery notes from OptimoRoute's address2 field.

OptimoRoute custom order fields (text single/multi-line, number with decimal places, single-select pick-list) map 1:1 to Dataverse custom fields on the routing custom table. Single-select values require a value-by-value mapping to preserve the exact pick-list options. We generate the Dataverse field schema (type, format, required flag) during migration planning.

OptimoRoute order statuses (pending, scheduled, in_progress, completed, failed, cancelled) map to D365 Opportunity StateCode and StatusCode values via explicit value mapping. 'completed' maps to StateCode=1 (Closed) with StatusCode=3 (Won); 'failed' and 'cancelled' map to StateCode=1 with StatusCode=4 (Lost). This preserves closed-order reporting in D365 pipeline views.

OptimoRoute POD data (digital signature image, delivery photos, driver notes) is downloaded from the OptimoRoute API as binary blobs and re-uploaded to D365 as Notes (for text notes) or FileAttachments on the corresponding Opportunity record. Signature images stored as file attachments with a custom flag field POD_Signature__c = true.

OptimoRoute time windows (earliest and latest acceptable delivery time) map to two custom Datetime fields on the Opportunity: Window_Start__c and Window_End__c. These are used by the dispatch team to manually schedule or by Power Automate flows to trigger routing logic in a new dispatcher tool. No native D365 time-window constraint mechanism exists.

OptimoRoute order priority (1–5 or high/medium/low depending on account config) maps to a custom pick-list field Priority__c on Opportunity. The same values are preserved; priority directly influences the order in which route stops are sequenced in the destination routing tool.

OptimoRoute skills-based routing rules (e.g., 'refrigeration', 'hazmat', 'heavy lift') do not map to any native D365 mechanism. We create a custom multi-select option-set field Skills_Required__c on the Opportunity and a matching Skills_Possessed__c field on SystemUser, enabling Power Automate to match drivers to orders based on skill alignment post-migration.

OptimoRoute vehicle capacity constraints (weight capacity, volume capacity, number of stops) are stored on the custom vehicle table (cror_vehicle) as numeric fields: Weight_Capacity_kg__c and Volume_Capacity_L__c. These are used by the dispatch team or Power Automate routing logic to validate vehicle assignment feasibility.

OptimoRoute stores per-driver cost settings: cost_per_hour, cost_per_km, fixed_daily_cost. These map to custom decimal fields on the SystemUser record (Cost_Per_Hour__c, Cost_Per_Km__c, Fixed_Daily_Cost__c). These fields are informational in D365 and do not trigger automated calculations. Cost analysis and route costing are performed in the new routing or dispatch tool post-migration, using these migrated values as baseline inputs for profitability reporting.

OptimoRoute allows tagging orders with custom labels (e.g., 'fragile', 'return', 'priority-customer'). We map these to a custom option-set field Order_Tags__c on Opportunity, creating matching values in Dataverse. Labels with many unique values across accounts require a pre-migration value-audit to avoid exceeding the option-set limit.

OptimoRoute logs driver interactions (customer calls, failed delivery attempts) as activity records. These map to D365 PhoneCall, Email, or Task records linked to the corresponding Opportunity or Contact. Original timestamps and driver-as-owner are preserved. No native OptimoRoute activity type maps directly to D365's activity model — each record type is chosen at migration time based on the OptimoRoute activity subtype.

Files attached to OptimoRoute orders (e.g., delivery manifests, BOLs) are downloaded and re-uploaded to D365 Notes or FileAttachments on the corresponding Opportunity. Large files (>4 MB) are stored in D365's SharePoint integration if configured. The original filename is preserved in the D365 object.

OptimoRoute stores customer name and contact on each order. We create D365 Account records for each unique customer, using the order's customer_name field. The primary contact (phone, email) migrates to the Account's primary Contact. Multiple orders from the same customer link to the same Account, collapsing duplicate customer records during migration.