Asset hierarchy sync breaks when updating maintenance asset master data - parent-child relationships lost

We’re facing a frustrating issue with our maintenance asset master data in 10.0.43. When we perform bulk updates to asset properties through the Asset Management module, the parent-child hierarchy relationships break, leaving orphaned assets with null parent references.

The problem manifests when updating asset functional locations or technical specifications on multiple assets simultaneously. We use the standard bulk edit feature in Asset Management, but after the update completes, we find that child assets lose their parent associations. This cascades into our maintenance schedules failing to execute at the correct hierarchy level.

Error pattern we’re seeing:


Asset ID: PUMP-2301-A
Parent Reference: NULL (expected: PUMP-2301)
Hierarchy Level: 0 (expected: 2)
Maintenance Schedule: Orphaned

Our asset hierarchy has three levels: facility > system > component. We have about 3,500 assets structured this way, and maintenance schedules are defined at the system level to cascade down. When the hierarchy breaks, our preventive maintenance workflows don’t trigger correctly. Has anyone dealt with similar parent-child relationship mapping issues during bulk asset updates?

I dealt with this exact issue last year during a similar facility reorganization. Beyond the entity approach mentioned above, you also need to be aware of how maintenance schedules are affected. Even if you preserve the hierarchy correctly, the maintenance schedule associations can still break if you’re not careful.

The maintenance schedules in D365 Asset Management have their own entity relationships that reference both the asset hierarchy and the functional location hierarchy. When you move assets to new functional locations, you need to update the maintenance plan associations separately. Otherwise, you end up with schedules that reference old location paths even though the assets have moved.

Let me provide you with a complete solution that addresses all aspects of your hierarchy and maintenance schedule issues:

1. Asset Hierarchy Entity Structure: The core problem is that the UI bulk edit doesn’t respect the MaintenanceAssetEntity’s hierarchy validation rules. When you update assets through the UI, it bypasses the entity framework’s referential integrity checks. You must use data entities for any operation that could affect hierarchy relationships.

Use this entity configuration:


Entity: MaintenanceAssetEntity
Key fields: AssetId, ParentAssetId, FunctionalLocationId
Update mode: Update existing
Validation: Full entity validation

2. Parent-Child Relationship Mapping: The critical step is maintaining the parent references during functional location changes. Export your current asset hierarchy to Excel using the MaintenanceAssetEntity. Your export must include these fields: AssetId, ParentAssetId, FunctionalLocationId, HierarchyLevel, AssetType.

In Excel, update the FunctionalLocationId values for your reorganization, but DO NOT modify ParentAssetId values. The entity framework will handle relocating the hierarchy as long as parent references remain intact. Sort your data by HierarchyLevel ascending before import - this ensures parents are updated before children.

Create a validation formula in Excel to verify parent-child integrity:


=IF(ParentAssetId<>"", COUNTIF(AssetIdRange, ParentAssetId)>0, TRUE)

This confirms every parent reference points to a valid asset in your update set.

3. Maintenance Schedule Dependency on Hierarchy: Maintenance schedules in Asset Management have dependencies on both the asset hierarchy and functional location hierarchy. When you move assets, the schedule associations don’t automatically update. You need a two-phase approach:

Phase 1: Update asset master data with new functional locations (preserving hierarchy as described above)

Phase 2: Update maintenance plan lines to reference the new functional location paths

Export MaintenancePlanLineEntity after your asset updates complete. Update the FunctionalLocationId fields to match your new structure, then reimport. The system will reassociate schedules with the correct hierarchy paths.

4. Bulk Update Validation Rules: Implement these validation rules before executing your updates:

  • Pre-update validation: Query your asset hierarchy to identify any existing orphaned assets (ParentAssetId references non-existent assets). Fix these first.
  • Hierarchy completeness check: Ensure all assets in an update batch include their complete hierarchy chain (parent, grandparent, etc.). Don’t update partial hierarchies.
  • Functional location validation: Verify new functional locations exist before updating assets. Invalid location references will cause the import to fail and potentially corrupt hierarchy.
  • Maintenance schedule audit: Document which schedules are associated with which assets/locations before updates. Use this as a checklist for Phase 2.

Step-by-Step Execution Plan:

  1. Export current asset data using MaintenanceAssetEntity (include all hierarchy fields)
  2. In Excel, update FunctionalLocationId values only - preserve all ParentAssetId relationships
  3. Sort by HierarchyLevel ascending (parents first)
  4. Validate parent-child references using the formula provided
  5. Import updated asset data through Data Management Framework with full validation enabled
  6. Verify hierarchy integrity: Query for NULL parent references and incorrect hierarchy levels
  7. Export MaintenancePlanLineEntity
  8. Update FunctionalLocationId references in maintenance plans to match new asset locations
  9. Import updated maintenance plan lines
  10. Test maintenance schedule execution at each hierarchy level

Critical Configuration Settings: In your Data Management project for the asset updates:

  • Enable “Validate on import”
  • Set “Skip staging” to No (you want to review staging data)
  • Configure error handling to stop on first error during testing
  • Use sequential execution, not parallel

Testing Approach: Before executing on your full 3,500 asset inventory:

  1. Select one complete asset hierarchy (facility > system > components) - maybe 20-30 assets
  2. Execute the update process on this test set
  3. Verify hierarchy integrity, functional location assignments, and maintenance schedule execution
  4. Document any issues and refine your process
  5. Then proceed with full-scale updates in batches (by facility or system group)

Post-Update Validation: Run these queries after your updates to verify success:

  • Count of assets with NULL ParentAssetId where hierarchy level > 0
  • Assets where functional location doesn’t match their parent’s functional location path
  • Maintenance schedules with no associated assets
  • Maintenance schedules with incorrect functional location references

This approach will preserve your asset hierarchy integrity while successfully relocating assets to new functional locations and maintaining your maintenance schedule associations. The key is using data entities instead of UI bulk edit, maintaining parent references throughout the process, and updating maintenance schedules as a separate coordinated step.

This is getting complicated. So we need to update assets through data entities to preserve hierarchy, but then also update maintenance schedules separately? Is there any way to do this as a coordinated operation, or do we really need to manage these as separate update processes? We have dozens of maintenance schedules that would need updating.

Yes, functional location updates are part of what we’re doing. We’re reorganizing our facility structure and need to move entire asset hierarchies to new functional locations. We assumed the bulk edit would maintain the parent-child relationships since we’re moving complete systems together, but apparently not.

Is there a specific sequence or method we should use for these updates? Should we be updating parent assets first, then children? Or is there a different approach altogether for maintaining hierarchy integrity during functional location changes?