Best-Practice Guidance for a Combined Asset Repair and Asset RMA Intake in HAM

ajha27
Tera Contributor

2 hours ago

We have a customer requirement in Hardware Asset Management (HAM) to provide a combined intake request for both Asset Repair and Asset RMA through a Asset Repair Record producer .

Our proposed approach is to build a custom Flow that evaluates the asset’s condition and warranty status:

  1. Asset under warranty
    Route the request through the out-of-box (OOB) Asset RMA process within the custom Flow.

  1. Asset not under warranty but beyond economic repair (BER)

    Route the request through the OOB Asset Repair process within the custom Flow.

The objective is to provide one consolidated intake experience while continuing to leverage the existing OOB Asset RMA and Asset Repair processes where applicable.

Before proceeding, we would appreciate guidance on the potential advantages, disadvantages, and technical considerations of this approach.

0 Helpfuls
  • 72 Views
1 REPLY 1

Suryansh Verma
Mega Sage

an hour ago

 

Hello @ajha27 ,

 

I am not an expert in HAM but a combined intake is a reasonable design, but I would keep the custom layer limited to intake, validation and routing, and then let the appropriate OOTB HAM process own the lifecycle.

I would implement a Decision Table in front of the HAM processes rather than putting all the conditions directly into the Flow:

 

 
Warranty + RMA eligible
→ OOTB Asset RMA

Out of warranty + internal repair candidate
→ OOTB Asset Repair

Known BER / unrepairable
→ Disposal

Unable to determine
→ Manual assessment

 

I would also be careful with the proposed "not under warranty + BER → Repair" rule. The OOTB Repair process is appropriate if BER still needs to be determined: its Troubleshoot task supports Repairable, Unrepairable and Redeployable outcomes, and selecting Unrepairable moves the asset to Pending disposal. If the asset is already confirmed BER before the request is submitted, initiating a Repair process may be unnecessary and a disposal route may be more appropriate.

Similarly, warranty status alone should not necessarily trigger RMA. RMA eligibility may also depend on the vendor/warranty agreement and existing RMA activity. The OOTB RMA Assessment task already determines whether repair will be on-site or off-site.

I would not customize the OOTB Asset RMA/Repair flows themselves. Use a custom orchestration Flow/Subflow to determine the destination, initiate the appropriate OOTB HAM record/process, and then let the OOTB lifecycle continue unchanged.

ServiceNow also provides Decision Tables for the RMA Flow, On-site RMA Flow and Off-site RMA Flow specifically as supported configuration points.

One other important consideration is asset state. The OOTB Asset Repair process is intended for defective/pending-repair assets in a stockroom. If the combined request can be submitted for an assigned/in-use asset, you may need a return/stockroom step before initiating Repair.

I would also check for an existing open RMA/Repair before creating another process and, if multiple assets can be submitted together, route each asset independently because some may qualify for RMA while others require Repair or Disposal.

So overall, one intake + a thin orchestration layer + OOTB fulfilment processes would be my preferred approach rather then building a combined replacement for the OOTB Repair and RMA workflows.

 

If my response helped, please mark it as correct and close the thread, this helps future readers find the solution faster!!!

0 Helpfuls