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