Reclamation Rule in SAM

Go to solution
abhijee
Tera Contributor

3 weeks ago

Hello Team,

I am new to the SAM (Software Asset Management) module and currently exploring reclamation rules. I want to ensure I understand the backend flow correctly.

I noticed that there are two different tables related to software usage:

  1. samp_sw_usage – Software Usage table
  2. cmdb_sam_sw_usage –Software Usage table

I would like to understand:

  • Which software usage table is actually used by the reclamation rule to identify and reclaim software?
  • Can someone explain the backend flow of how the reclamation rule works to reclaim software licenses?
  • Are software licenses reclaimed automatically by the rule, or do we need to reclaim them manually?

Your guidance will be really helpful.

Thank you

0 Helpfuls
  • 1,169 Views
1 ACCEPTED SOLUTION

Go to solution
SAMfluencer
ServiceNow Employee

3 weeks ago

Hi @abhijee ,

 

Great question, Let me break this down properly, and I'll add a section specifically for anyone running SCCM as their usage source, because there is a critical prerequisite step before reclamation can work at all.

 

1. Which Table Does the Reclamation Rule Actually Use?

 

There are two Software Usage tables in ServiceNow and both appear as "Software Usages" in the navigator which is exactly why the confusion happens.

 

samp_sw_usage -> Current / Active -> User, Publisher, Product, CI, Reclamation Type, Usage Type

cmdb_sam_sw_usage -> Legacy -> Display Name, Version, Discovery Model, Accessed From, Duration

 

The clearest giveaway is the Reclamation Type field - it sits directly on samp_sw_usage, confirming this is the table the Reclamation Rule engine evaluates. cmdb_sam_sw_usage was part of the older CMDB-aligned data model and does not carry reclamation-specific fields in modern SAM Pro instances.

 

2. Backend Flow - How Reclamation Works End to End

 

Discovery ACC Agent/ SCCM

↓

Software install recorded → cmdb_sam_sw_install

↓

Usage data populated → samp_sw_usage (Last Used Time, Total Minutes Used, Usage Type, Reclamation Type stamped per user/CI)

↓

Reclamation Rule evaluated (e.g. "No usage in last 30/60/90 days" - only installs with a managed entitlement are evaluated)

↓

Reclamation Task created → (User / manager notified; dispute window opens - typically 7–14 days)

↓

No dispute → License returned to entitlement pool (alm_license)

 

Two fields in samp_sw_usage are central to how the rule makes its decision:

 

  • last_used - the Last Used Time stamp from your metering source
  • minutes_used - Total Usage Time (cumulative minutes from SCCM metering)

If either of these fields is empty across your records, the reclamation rule is essentially flying blind. Which brings me to the most important part of this response.

 

IMPORTANT - If You Are Using SCCM as Your Usage Source, Read This Before Configuring Reclamation:

 

Before you even think about enabling Reclamation Rules, you need to verify that your SCCM integration is actually populating samp_sw_usage correctly. In my experience across multiple implementations, this is the most commonly missed step - and it will silently break your entire reclamation programme.

 

Check 1 -  Is the SG-SCCM Software Last Used scheduled job actually active?

 

Navigate to: SGC for SCCM → Scheduled Data Imports → SG-SCCM Software Last Used

 

This is the dedicated job that imports the LastUsedTime field from SCCM into samp_sw_usage.last_used. If Active = false or the Last Run Datetime is blank, your last_used field will be empty across every single record — regardless of what SCCM has captured. The Reclamation Rule cannot identify dormant users without this data.

Also check: SG-SCCM Software Edition job. If this is also disabled, your software edition data (Standard, Professional, Enterprise) will be missing  this affects how installs are identified and matched against entitlements.

 

Check 2 - Does the Data Source have a proper SQL Server connection configured?

Check 3 - Is your SQL query hardcoded to specific applications or a fixed time period?

Check 4 - How frequently does your SAMP Usage job run?

 

3. Automatic vs Manual Reclamation : Both modes are supported. The behaviour is controlled entirely by your Reclamation Rule configuration.

 

Recommendation: If you are in early rollout, start with auto-reclaim disabled. Run a few manual cycles first to validate that samp_sw_usage is being populated correctly by your connector - specifically that last_used and minutes_used are not empty. False positives from stale or missing usage data will cause unnecessary friction in the SAM programme before it gets off the ground.

 

One important distinction worth calling out here:

 

For installed software, there are no OOB Reclamation Rules - you will need to create these manually. You define the inactivity threshold, the notification window, the dispute handling behaviour, and the target entitlement pool yourself. This is also why validating your samp_sw_usage data pipeline first is so critical - a manually configured rule built on bad data will produce bad reclamation candidates.

 

For SaaS applications, Reclamation Rules are available Out-of-the-Box. ServiceNow ships pre-configured rules for SaaS products, as usage data flows from SaaS connectors (e.g. Adobe CC, Microsoft 365) through a managed reconciliation process that ServiceNow controls end to end. You still need your SaaS connectors healthy and reconciliation running cleanly, but the reclamation rule logic itself does not need to be built from scratch.

 

If this helped - amazing, you're welcome, go click Helpful and Accept as Solution. If it didn't - well, at least you learned what not to do. Either way, we grow. 

 

Cheers, Abby

ITAM Principal Solution Architect

View solution in original post

0 Helpfuls
4 REPLIES 4

Go to solution
Tanushree Maiti
Kilo Patron

3 weeks ago

 

 

Please mark this response as Helpful & Accept it as solution if it assisted you with your question.
Regards
Tanushree Maiti
ServiceNow Technical Architect
Linkedin:

Go to solution
SAMfluencer
ServiceNow Employee

3 weeks ago

Hi @abhijee ,

 

Great question, Let me break this down properly, and I'll add a section specifically for anyone running SCCM as their usage source, because there is a critical prerequisite step before reclamation can work at all.

 

1. Which Table Does the Reclamation Rule Actually Use?

 

There are two Software Usage tables in ServiceNow and both appear as "Software Usages" in the navigator which is exactly why the confusion happens.

 

samp_sw_usage -> Current / Active -> User, Publisher, Product, CI, Reclamation Type, Usage Type

cmdb_sam_sw_usage -> Legacy -> Display Name, Version, Discovery Model, Accessed From, Duration

 

The clearest giveaway is the Reclamation Type field - it sits directly on samp_sw_usage, confirming this is the table the Reclamation Rule engine evaluates. cmdb_sam_sw_usage was part of the older CMDB-aligned data model and does not carry reclamation-specific fields in modern SAM Pro instances.

 

2. Backend Flow - How Reclamation Works End to End

 

Discovery ACC Agent/ SCCM

↓

Software install recorded → cmdb_sam_sw_install

↓

Usage data populated → samp_sw_usage (Last Used Time, Total Minutes Used, Usage Type, Reclamation Type stamped per user/CI)

↓

Reclamation Rule evaluated (e.g. "No usage in last 30/60/90 days" - only installs with a managed entitlement are evaluated)

↓

Reclamation Task created → (User / manager notified; dispute window opens - typically 7–14 days)

↓

No dispute → License returned to entitlement pool (alm_license)

 

Two fields in samp_sw_usage are central to how the rule makes its decision:

 

  • last_used - the Last Used Time stamp from your metering source
  • minutes_used - Total Usage Time (cumulative minutes from SCCM metering)

If either of these fields is empty across your records, the reclamation rule is essentially flying blind. Which brings me to the most important part of this response.

 

IMPORTANT - If You Are Using SCCM as Your Usage Source, Read This Before Configuring Reclamation:

 

Before you even think about enabling Reclamation Rules, you need to verify that your SCCM integration is actually populating samp_sw_usage correctly. In my experience across multiple implementations, this is the most commonly missed step - and it will silently break your entire reclamation programme.

 

Check 1 -  Is the SG-SCCM Software Last Used scheduled job actually active?

 

Navigate to: SGC for SCCM → Scheduled Data Imports → SG-SCCM Software Last Used

 

This is the dedicated job that imports the LastUsedTime field from SCCM into samp_sw_usage.last_used. If Active = false or the Last Run Datetime is blank, your last_used field will be empty across every single record — regardless of what SCCM has captured. The Reclamation Rule cannot identify dormant users without this data.

Also check: SG-SCCM Software Edition job. If this is also disabled, your software edition data (Standard, Professional, Enterprise) will be missing  this affects how installs are identified and matched against entitlements.

 

Check 2 - Does the Data Source have a proper SQL Server connection configured?

Check 3 - Is your SQL query hardcoded to specific applications or a fixed time period?

Check 4 - How frequently does your SAMP Usage job run?

 

3. Automatic vs Manual Reclamation : Both modes are supported. The behaviour is controlled entirely by your Reclamation Rule configuration.

 

Recommendation: If you are in early rollout, start with auto-reclaim disabled. Run a few manual cycles first to validate that samp_sw_usage is being populated correctly by your connector - specifically that last_used and minutes_used are not empty. False positives from stale or missing usage data will cause unnecessary friction in the SAM programme before it gets off the ground.

 

One important distinction worth calling out here:

 

For installed software, there are no OOB Reclamation Rules - you will need to create these manually. You define the inactivity threshold, the notification window, the dispute handling behaviour, and the target entitlement pool yourself. This is also why validating your samp_sw_usage data pipeline first is so critical - a manually configured rule built on bad data will produce bad reclamation candidates.

 

For SaaS applications, Reclamation Rules are available Out-of-the-Box. ServiceNow ships pre-configured rules for SaaS products, as usage data flows from SaaS connectors (e.g. Adobe CC, Microsoft 365) through a managed reconciliation process that ServiceNow controls end to end. You still need your SaaS connectors healthy and reconciliation running cleanly, but the reclamation rule logic itself does not need to be built from scratch.

 

If this helped - amazing, you're welcome, go click Helpful and Accept as Solution. If it didn't - well, at least you learned what not to do. Either way, we grow. 

 

Cheers, Abby

ITAM Principal Solution Architect

0 Helpfuls

Go to solution
abhijee
Tera Contributor
In response to SAMfluencer

3 weeks ago

Hello @SAMfluencer ,

Thank you for your response.

I have below query could you please guide me.

I have installation data for a specific CI (xyz CI), and I have manually created software usage records for that CI. I have also configured a software reclamation rule and created a software entitlement for the software model (Miro).

I executed the out-of-the-box (OOTB) scheduled job for reclamation; however, no removal candidates are being generated. I would like to understand the possible reasons for this.

Additionally, I have a question regarding the reclamation process: once the reclamation is completed, how does the system determine which software entitlement allocation should be updated? This is because the reclamation rule has been configured at the product level rather than the model level.

Thank You.

0 Helpfuls

Go to solution
SAMfluencer
ServiceNow Employee
In response to abhijee

3 weeks ago

Hi @abhijee ,

 

I have provided the suggestion here : https://www.servicenow.com/community/sam-forum/reclamation-job-executed-but-no-removal-candidates-cr...

 

Regards,

Abby

0 Helpfuls