Skip to main content

Troubleshooting Damage, Loss, Retirement, and Deletion

Summary​

This page covers the damage, loss, retirement, and deletion operations and their effect on clearance. Marking damaged and marking lost share a single event, AssetLostOrDamaged; the status and condition distinguish the two. Repair is a status and condition, not a separate event. Retirement moves the asset to Retired, which is terminal. Deletion is a separate operation exposed through the compatibility delete. Clearance-blocking statuses are Issued, Damaged, Lost, and Repair; non-blocking statuses are Returned, Available, Rejected, and Retired. There is no theft-specific or disposal workflow. The asset tab exposes approve, reject, and delete only, with no damage, lost, or retire buttons.

Audience​

Support engineers and developers investigating how damage and loss are distinguished, why clearance is blocked, or why certain actions are not available in the portal.

Symptoms​

  • Damage and loss appear indistinguishable because they share one event.
  • Clearance is blocked for an employee holding an asset.
  • A user cannot find damage, lost, or retire buttons in the asset tab.
  • A retired asset cannot be transitioned further.

Cause​

Scope​

This page covers the damage, loss, repair, retirement, and deletion transitions and the clearance-blocking status set. Notification behavior for these events is covered on the notifications page.

Likely causes​

  • Damage and loss share the AssetLostOrDamaged event, so distinguishing them requires reading status and condition rather than the event type.
  • The asset holds a clearance-blocking status (Issued, Damaged, Lost, or Repair), so clearance is blocked by design.
  • The asset tab exposes only approve, reject, and delete, so damage, lost, and retire are exercised through the API, not the tab.
  • The asset is Retired, which is terminal, so no further transition is possible.

Resolution​

Safe diagnostics​

  • Read status and condition together to distinguish damaged from lost, since they share one event.
  • Compare the asset's status against the clearance-blocking set to confirm why clearance is blocked.
  • Confirm whether the intended action is available in the asset tab or must be issued through the API.
  • Treat Retired as terminal; do not expect a further transition from it.

Validation​

  • Confirm status and condition reflect the intended damage, loss, repair, or retirement outcome.
  • Confirm clearance status aligns with the blocking and non-blocking sets.
  • Confirm an AssetLostOrDamaged or AssetRetired row is present in the outbox diagnostics where expected.

Evidence to Collect​

  • The asset status and condition before and after.
  • The clearance status observed for the holder.
  • Which surface was used to attempt the action.
  • A correlation identifier and timestamp.

Escalation​

Route status and condition modeling to the asset or backend team. Route missing portal controls to the frontend team. Route clearance-policy questions to the asset team and the owning exit or clearance process owner where named; where a named owner is not established, treat it as Requires confirmation.

Source References​

  • microservices/src/asset-service/Domain/Asset/Asset.cs
  • microservices/src/asset-service/Domain/Common/Enums.cs
  • microservices/src/asset-service/Api/AssetCompatEndpoints.cs

See Also​

Keywords​

damage, loss, retirement, deletion, clearance

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-17
  • Review cycle: Quarterly