Handling Disabled or Non-Human Accounts in ServiceNow SAM User Subscriptions

[stefantaitano]

In a SAM Workspace implementation, we've identified a large number of User Subscription records linked to M365 Integration profiles that do not have corresponding User records in ServiceNow. Upon further investigation:

• A small subset of these subscriptions do match existing ServiceNow users.
• The majority appear to be shared mailboxes, group accounts, or seasonal/temporary workers whose accounts are disabled in Active Directory.
• These accounts are not currently represented in ServiceNow, which limits visibility and reclamation capabilities.

We're considering adjusting LDAP OU filters to include disabled accounts, but we're unsure if this is the best approach.

Questions:

1. What is the recommended best practice for handling subscriptions tied to disabled or non-human accounts in ServiceNow SAM?
2. Is it advisable to bring in disabled AD accounts via LDAP just for visibility and reclamation purposes?
3. Are there alternative approaches to managing these types of subscriptions without cluttering the User table?

Any guidance or shared experiences would be appreciated!

[Subhendu1]

Most of the unmatched M365 subscriptions are linked to shared mailboxes, service accounts, or disabled AD users not present in ServiceNow. It’s not recommended to import these into the  sys_user table, as that adds unnecessary clutter. Instead, keep them visible through the Unmatched Subscriptions view or a separate import for reporting and reclamation. Reclamation rules can then target disabled or inactive accounts based on data from Azure AD. This approach maintains visibility and control without impacting platform performance.

Please mark helpful if that solves.
Best regards,
Subhendu

[stefantaitano]

I'm curious on your effort and configuration of setting up reclamation rules for disabled/inactive accounts. How did you do this? Screenshots by chance?

[stefantaitano]

Hello all, I was able to get guidance from the ServiceNow SAM Open Office hours on October 21, 2025, and here are the insights:

What Others Are Doing

1. Discovered User Records

   • If an assigned user isn’t found in the User table, ServiceNow creates a Discovered User record for reconciliation.
   • Add the Discovered User column to your list view for visibility.
   • Caution: Reclamation may not use this field directly—verify orchestration variables if automating reclaim.

2. Custom Reporting

   • No out-of-the-box report exists for disabled accounts.
   • ServiceNow staff recommend creating a custom report to identify offboarding gaps and subscriptions tied to disabled users. This helps asset managers reclaim licenses effectively.

3. Contract Review

   • Ensure contracts do not charge for disabled/non-human accounts. This is a critical cost-control measure.

4. Scripted Automation

   • Customer scripted processes to:
     • Dynamically create ServiceNow user records for non-human accounts based on subscription data.
     • Automatically set these accounts inactive when no longer needed.
   • One customer achieved ~75% automation, with manual cleanup for the remaining 25%.
   • If SAM visibility is your only goal and you have scripting resources, this approach can save time.

5. Security Considerations

   • Adding non-legitimate users to the User table can introduce risk (e.g., login.do exposure).
   • Alternative: Treat these as machine-only interventions and mark them inactive immediately.

[lakshmin]

Hi stefantaitano

Are these sessions recorded by any chance ?or any online reference

We are on the pointer 4 trying to script the non human accounts to the User table - Was this approach a No-No as per the Office hours due to the security concerns - are there others to consider apart from login.do?

Thanks

Lann