EIB migration for work orders fails due to unmapped status values in wd-r2-2023

ERP Workday
, , , , , , , ,
1

We’re migrating 1,800 historical work orders from our legacy maintenance system to Workday work-order-mgmt module using EIB. The import validation keeps failing with ‘Invalid status value’ errors for about 40% of our records. Our legacy system uses status codes like ‘OPEN’, ‘INPROG’, ‘COMPLETE’, ‘CANCELLED’, but Workday’s EIB template shows different status values.

I’ve tried mapping our legacy statuses to what I think are Workday equivalents (‘OPEN’ → ‘Open’, ‘INPROG’ → ‘In Progress’, etc.) but the validation still fails. The EIB error report doesn’t clearly explain what valid status values are accepted. We need these historical work orders loaded to maintain maintenance history for our assets and equipment, especially for warranty tracking and compliance reporting. Has anyone successfully mapped legacy work order statuses to Workday’s expected values?

2

I checked our tenant configuration and found these statuses: ‘New’, ‘Assigned’, ‘In Progress’, ‘On Hold’, ‘Completed’, ‘Closed’, ‘Cancelled’. So my legacy ‘OPEN’ should map to ‘New’, ‘INPROG’ to ‘In Progress’, ‘COMPLETE’ to ‘Completed’. But what about work orders that were closed in our legacy system - should I use ‘Completed’ or ‘Closed’? Is there a functional difference?

3

One more consideration for your status mapping: if work orders have related maintenance schedules or asset history dependencies, the status affects reporting and analytics. Closed work orders may not appear in some standard reports. Verify which historical data you need accessible for warranty tracking and compliance - you might want some historical orders in ‘Completed’ status rather than ‘Closed’ to keep them visible in maintenance history reports.

4

The issue is that Workday doesn’t use simple string status values - it uses status references that point to configured status objects in your tenant. You need to find the exact status names configured in your Workday instance. Go to Work Order Management setup and look at the configured work order statuses. These are tenant-specific and may differ from standard Workday defaults if your implementation team customized them.

5

Here’s a comprehensive solution covering all three focus areas:

Status Code Mapping: Workday work order statuses are configured objects, not free-text values. Your mapping must use exact status names from your tenant configuration.

Based on your tenant’s configured statuses, here’s the recommended mapping:


Legacy Status → Workday Status → Usage
OPEN → New → Work orders created but not assigned
ASSIGNED → Assigned → Work orders assigned to technician (if this status exists in your tenant)
INPROG → In Progress → Active work in progress
ONHOLD → On Hold → Work paused (waiting for parts, approvals, etc.)
COMPLETE → Closed → Historical completed work (recommended for migration)
CANCELLED → Cancelled → Work orders that were cancelled
DEFERRED → On Hold → Deferred maintenance (use On Hold if DEFERRED doesn't exist)
WAITING → On Hold → Waiting for parts/resources

Key mapping decisions for historical migration:

  1. Completed Work Orders: For historical data (not requiring further action), map to ‘Closed’ rather than ‘Completed’:
  • Reason: ‘Closed’ indicates finalized state, prevents accidental reopening
  • Benefit: Cleaner active work order list, historical data still accessible for reporting
  • Exception: If warranty tracking requires ‘Completed’ status for specific reports, use ‘Completed’ for orders within warranty period
  1. In-Progress Historical Orders: For work orders that were in progress when you migrated:
  • If work will continue in Workday: Use ‘In Progress’ and assign to current technician
  • If work was abandoned: Use ‘Cancelled’ with completion notes explaining migration cutover
  • If work was actually finished but not closed in legacy: Use ‘Closed’ with actual completion date
  1. Non-Standard Legacy Statuses: Your legacy system likely has custom statuses. Audit your source data:

SELECT DISTINCT status, COUNT(*)
FROM legacy_work_orders
GROUP BY status

Common non-standard statuses and mapping:

  • ‘HOLD-PARTS’ → ‘On Hold’ (add note: “Waiting for parts”)
  • ‘WAITING-APPROVAL’ → ‘On Hold’ (add note: “Pending approval”)
  • ‘REWORK’ → ‘In Progress’ (add note: “Rework required”)
  • ‘DEFERRED’ → ‘On Hold’ or create custom ‘Deferred’ status if significant volume
  • ‘PENDING’ → ‘New’ or ‘Assigned’ based on whether technician assigned
  1. Status Validation in CSV: Your EIB CSV must use exact status names (case-sensitive, spacing-sensitive):

Work_Order_ID,Description,Status,Completion_Date
WO-00001,Pump repair,Closed,2024-12-15
WO-00002,HVAC maintenance,In Progress,
WO-00003,Safety inspection,Cancelled,2024-11-20

Not valid: ‘closed’, ‘CLOSED’, ‘In_Progress’, ‘InProgress’

EIB Import Validation:

Step-by-step validation process:

  1. Pre-Import Data Validation: Before running EIB, validate your CSV:

a. Status Value Check:


// Pseudocode - Validation script:
1. Load valid Workday statuses from tenant configuration
   Valid_Statuses = ['New', 'Assigned', 'In Progress', 'On Hold', 'Completed', 'Closed', 'Cancelled']

2. Read work order CSV file
   For each row:
     If Status NOT IN Valid_Statuses:
       Log error: "Invalid status '{Status}' in row {RowNumber}"
       Add to error report

3. Generate mapping report:
   Legacy_Status | Count | Mapped_To | Validation_Status
   OPEN          | 450   | New       | Valid
   COMPLETE      | 720   | Closed    | Valid
   INPROG        | 380   | In Progress| Valid
   HOLD-PARTS    | 150   | On Hold   | Needs Review

b. Required Field Validation:

Beyond status, validate other required fields:

  • Work Order ID: Must be unique, non-null
  • Asset Reference: Must exist in Workday (validate against asset list)
  • Work Order Type: Must match configured types in tenant
  • Completion Date: Required for ‘Closed’ and ‘Completed’ statuses, must be YYYY-MM-DD format
  • Assigned To: Required for ‘Assigned’ and ‘In Progress’ statuses

c. Business Logic Validation:

  • If Status = ‘Closed’ or ‘Completed’, Completion_Date must be populated
  • If Status = ‘In Progress’, Assigned_To must be populated
  • If Status = ‘Cancelled’, Cancellation_Date should be populated
  • Start_Date must be before Completion_Date
  • Work orders cannot be closed before they were created
  1. EIB Template Configuration:

a. Download fresh EIB template for Work Orders:

  • Navigate to: Integration > EIB > Create EIB
  • Select: Work Order Management
  • Choose: Work Order template
  • Download template (includes all valid fields and format requirements)

b. Key template fields for status-related import:

  • Work_Order_Status (required): Use exact status name from your tenant
  • Completion_Date (conditional): Required if status is Closed/Completed
  • Status_Change_Date (optional): Date status was last changed
  • Status_Notes (optional): Explanation of status (useful for historical context)

c. Populate CSV following template exactly:

  • Use template column headers without modification
  • Maintain column order as in template
  • Use UTF-8 encoding without BOM
  • Date format: YYYY-MM-DD consistently throughout
  1. Test Import Process:

a. Phase 1 - Status validation test (50 records):

  • Select 10 work orders for each major status (New, In Progress, Closed, Cancelled, On Hold)
  • Run EIB import in test environment
  • Review validation report for any status errors
  • Verify imported work orders show correct status in Workday UI

b. Phase 2 - Edge case testing (100 records):

  • Include work orders with:
    • Multiple status transitions in legacy system (use final status)
    • Missing completion dates (add placeholder dates for closed orders)
    • Unusual legacy statuses (verify mapping logic)
    • Very old work orders (10+ years) to test date handling
  • Validate imported data appears correctly in Work Order reports

c. Phase 3 - Volume test (500 records):

  • Test batch processing with larger dataset
  • Monitor import performance and error rates
  • Verify no timeout or memory issues
  • Confirm all statuses import successfully at scale
  1. Error Handling:

When EIB validation fails:

a. Download validation report:

  • EIB generates detailed error report showing:
    • Row number with error
    • Field causing error
    • Error message
    • Expected vs actual value

b. Common status-related errors and fixes:

Error: “Invalid status value ‘COMPLETE’”

Fix: Change to ‘Completed’ or ‘Closed’ (exact match to tenant config)

Error: “Status ‘Closed’ requires Completion Date”

Fix: Add completion date in YYYY-MM-DD format

Error: “Status transition not allowed”

Fix: Use final status only (Workday validates status workflow, historical imports should use end state)

Error: “Status reference not found”

Fix: Status name has typo or doesn’t exist in tenant (verify tenant configuration)

c. Bulk error correction:

  • Export error rows from validation report
  • Apply fixes in bulk using Excel formulas
  • Re-import corrected records

Work Order Migration Best Practices:

  1. Historical Data Strategy:

Decide what historical data to migrate based on business needs:

a. Warranty Tracking Requirements:

  • Migrate all work orders for assets still under warranty
  • Status: Use ‘Closed’ but ensure completion dates are accurate
  • Include: Asset ID, work performed, parts used, labor hours
  • Timeframe: Typically 3-5 years or warranty period

b. Compliance Reporting Requirements:

  • Migrate safety-related work orders (regulatory compliance)
  • Migrate preventive maintenance history (audit trail)
  • Status: ‘Closed’ with accurate completion dates and compliance notes
  • Timeframe: Depends on regulatory requirements (often 7+ years)

c. Maintenance History Requirements:

  • Migrate work orders for critical assets (baseline maintenance patterns)
  • Include recurring issues to identify problem equipment
  • Status: ‘Closed’ for completed, ‘Cancelled’ for abandoned
  • Timeframe: 2-3 years for trending analysis

d. Selective Migration Approach:


// Migration priority matrix:
Asset_Criticality | Work_Order_Age | Migrate?
Critical          | 0-5 years      | Yes - Full detail
Critical          | 5+ years       | Yes - Summary only
Important         | 0-3 years      | Yes - Full detail
Important         | 3+ years       | No - Archive externally
Standard          | 0-2 years      | Yes - Full detail
Standard          | 2+ years       | No - Archive externally
  1. Data Cleansing Before Migration:

a. Status standardization:

  • Consolidate similar legacy statuses (COMPLETE/COMPLETED/DONE → Closed)
  • Resolve ambiguous statuses with business owners
  • Document mapping decisions in migration guide

b. Completion date cleanup:

  • Set completion date = last updated date for closed orders missing completion date
  • Validate completion dates are not future dates
  • Ensure completion date >= start date

c. Asset linkage validation:

  • Verify all work order asset references exist in Workday
  • For orphaned work orders (asset not migrated), decide:
    • Skip migration (archive externally)
    • Create placeholder asset
    • Link to parent asset/location
  1. Status-Specific Migration Rules:

a. ‘Closed’ Status Work Orders:

  • Required fields: Work_Order_ID, Asset_ID, Description, Status=‘Closed’, Completion_Date
  • Optional but recommended: Work_Performed, Labor_Hours, Parts_Used, Total_Cost
  • Benefit: Provides complete maintenance history for analytics

b. ‘Cancelled’ Status Work Orders:

  • Required fields: Work_Order_ID, Status=‘Cancelled’, Cancellation_Date, Cancellation_Reason
  • Use for: Work orders that were created but never executed
  • Benefit: Maintains complete audit trail of all work order activity

c. ‘In Progress’ Status Work Orders (cutover items):

  • Required fields: Work_Order_ID, Asset_ID, Status=‘In Progress’, Assigned_To, Start_Date
  • Approach: Migrate only if work will continue in Workday
  • Alternative: Close in legacy system before migration, start fresh in Workday
  1. Post-Migration Validation:

a. Status distribution report:


Run report: Work Orders by Status
Expected distribution:
Closed: ~720 (40% of total)
Cancelled: ~180 (10%)
New: ~450 (25%)
In Progress: ~380 (21%)
On Hold: ~70 (4%)

Compare to legacy system status distribution
Investigate significant variances

b. Data quality checks:

  • All ‘Closed’ work orders have completion dates
  • All ‘In Progress’ work orders have assigned technicians
  • No work orders with completion date but status ≠ Closed/Completed
  • Asset references are valid (no orphaned work orders)

c. Reporting validation:

  • Run standard Work Order reports (by asset, by status, by date range)
  • Verify maintenance history appears correctly for sample assets
  • Test warranty tracking reports show relevant work orders
  • Confirm compliance reports include required historical data
  1. Migration Timeline:

Week 1: Data analysis and status mapping

  • Audit legacy status values
  • Document mapping decisions
  • Validate tenant status configuration
  • Create mapping reference document

Week 2: Data cleansing and preparation

  • Standardize legacy statuses using mapping
  • Clean completion dates and required fields
  • Validate asset references
  • Create final migration CSV

Week 3: Testing and validation

  • Test import 50 records (all statuses)
  • Test import 100 edge cases
  • Test import 500 volume test
  • Fix any validation errors

Week 4: Production migration

  • Import historical closed work orders (720 records)
  • Import cancelled work orders (180 records)
  • Import active work orders (830 records)
  • Run post-migration validation reports
  • Document any issues for reference

This systematic approach ensures your 1,800 work orders migrate successfully with correct status mapping, maintaining your maintenance history for warranty tracking and compliance reporting.