Is there a way to safely configure the "Eligible for Refresh" scheduled job?

[WB]

Problem:  The "Eligible for Refresh" field on an asset is set by an OOB scheduled job that uses the "created on" date, and the model's useful life value to determine eligibility, but in our environment the "Created on" date is generated when the asset record is created for the 1st time by Discovery, which typically finds the asset years after it's already been in production.  Therefore, the scheduled job is not flagging assets as eligible. 

For example, Discovery found a four year old device for the first time, added it to ServiceNow with a "Created On" date of today.  The Model has a "useful life" of 48 months, so the OOB job won't set this as eligible for refresh until year 8.     

My organization is interested in using the OOB "Eligible for Refresh" field to support our Refresh Planning. 
My organization is reluctant to change any feature that is OOB.

Is there an acceptable way to configure the OOB "Eligible for Refresh" scheduled job to use a different date field (i.e. purchased or warranty expiration) to drive the "eligibility logic", such that we will not encounter problems during upgrades nor break the HAM Pro Refresh features?

Thank you in advance for any advice or alternative documentation you have for solving this problem.    

----------------------------------
ServiceNow Documentation explaining the "Eligible for refresh" field on alm_hardware records is based on the "created on date".  https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0829089

[Amit Gujarathi · Accepted solution]

HI @WB ,
I trust you are doing great.

Here's a suggested approach:

1. Identify the preferred date field: Determine which date field, such as "purchased" or "warranty expiration," you want to use as the basis for eligibility logic. Let's assume you choose the "purchased" date field for this solution.

2. Customize the scheduled job: Instead of modifying the existing OOB scheduled job, we'll create a new custom scheduled job that will run alongside the OOB job.

3. Create a new custom scheduled job: Write a custom scheduled job script that calculates the eligibility based on the "purchased" date field and updates the "Eligible for Refresh" field accordingly. Below is an example code snippet for the custom scheduled job script:

var hardwareGr = new GlideRecord('alm_hardware');
hardwareGr.addQuery('install_status', 'IN', '1,2,3'); // Filter assets in production
hardwareGr.query();

while (hardwareGr.next()) {
  var purchasedDate = hardwareGr.purchase_date; // Modify with the actual date field name

  // Calculate eligibility based on purchased date and useful life
  var usefulLifeMonths = 48; // Modify with the actual useful life value
  var eligibilityDate = new GlideDateTime(purchasedDate);
  eligibilityDate.addMonths(usefulLifeMonths);

  // Update the "Eligible for Refresh" field if the calculated date is in the past
  if (eligibilityDate < new GlideDateTime()) {
    hardwareGr.eligible_for_refresh = true;
    hardwareGr.update();
  }
}

1. Schedule the custom job: Configure the custom scheduled job to run at regular intervals, similar to the existing OOB job. You can set the schedule based on your organization's requirements.

[WB]

Thank you for the quick response, very helpful!

[Shane Sumsion]

This doesn't appear to be accounting for Models' diverse 'Useful Life' values. Thoughts ? 
: 

PS - I can read the code in general, but am not experienced with writing SN code.