Does M365 subscription assignment age affect low-usage removal candidate creation?

[pavan Punna]

We investigated an issue where Visio removal candidates were not being generated as expected. After importing the latest Visio usage CSV and running the M365 usage and reclamation jobs, 590 valid candidates were created, but 10 subscriptions with inactive days greater than 90 did not receive candidates.

The Visio reclamation rule shows a 90-day last activity threshold. However, we found that the Subscription assigned date for all 10 missing candidates was less than 90 days old, while all 590 successful candidates had an assignment age greater than 90 days.

We checked other M365 low-usage products and found the same pattern: no candidates were created before the subscription assignment age reached the applicable rule threshold.

Can someone confirm whether M365 low-usage candidate generation requires both the inactivity threshold and the subscription assignment age to meet the rule threshold? If confirmed, can we consider the 10 subscriptions correctly excluded until their assignment age reaches 90 days?

[Maniteja_2003 · Accepted solution]

Hi @pavan Punna ,

I hope this answer helps.

Your assumption is accurate. M365 low-usage removal candidate generation requires two conditions to be met.

First, the subscription's assigned/created date must be older than the configured threshold. If the subscription's external created/assigned date is not available, the system considers the Created date.

Once this condition is met, the system checks the Last Activity date. The subscription is considered stale when the Last Activity date is older than the configured threshold. If both conditions are satisfied, the subscription can proceed for low-usage removal candidate creation.

You can check the generateRCForProductSubscription method in the SampO365Admin Script Include, which contains the logic for determining whether a subscription is stale and eligible for removal candidate creation.

https://<instance-name>.service-now.com/sys_script_include.do?sys_id=f2081222eb203110a50ea51ef152282...

Thanks,
Maniteja.

[nataliagonc]

Hi @Maniteja_2003 ,
>M365 low-usage removal candidate generation requires two conditions to be met
Does the same logic apply to any SaaS or to M365 only?

[Maniteja_2003]

Hi @nataliagonc,

I hope this answer helps you.

For other SaaS integrations, the SAMSaaSReclamationUtil Script Include contains the generateReclamationCandidatesForProduct method, which generates reclamation candidates. This method calls the isStale method to determine whether a subscription is stale based on additional attributes. Subscriptions identified as stale (isStale = true) are considered for reclamation.

Script Include Link: 
https://<instance-name>.service-now.com/sys_script_include.do?sys_id=d89b7023532011107f77ddeeff7b121...

Thanks,
Maniteja.

[nataliagonc]

Hi @Maniteja_2003 ,

Thanks for pointing to SAMSaaSReclamationUtil — that confirms there’s a separate mechanism for non-M365 SaaS, but I want to clarify the specific logic.

For M365, the first answer in this thread confirmed a two-condition gate: a subscription only becomes eligible for a reclamation candidate once both the assignment/created date age and the last activity age exceed their respective thresholds.

Does the same two-condition logic apply inside isStale in SAMSaaSReclamationUtil for generic SaaS products — i.e., is assignment/created date age checked as a separate gating condition, the same way it is for M365 — or does isStale rely solely on last activity date, with no assignment-age gate at all?

Thanks,
Natalia