Best Practice for Downgrading Inactive Users

[Anupam1]

We have several inactive users (no login for 60+ days) who still hold ITIL/write roles. Many of these roles are inherited from groups.

Before downgrading them to Business Stakeholder, I want to confirm:

• Does any write role (direct or inherited) automatically require an ITIL fulfiller license?

• If a user inherits sn_change_write or itil from a group, is removing direct write roles insufficient to reduce license usage?

• What is the best practice for handling groups that grant write roles to users who do not perform fulfiller activities?

Looking for guidance on the correct governance approach.

[AndersBGS]

Hi @Anupam1 

Notice that write is requiring an ITIL role license. Business stakeholder is only read and approvals.

[Anupam1]

Thanks, Anders — that clarifies the license behavior for write vs read roles.

I have a follow‑up scenario: We are trying to downgrade users who haven’t logged in for 60+ days. Many of them are still active and continue to consume ITIL fulfiller licenses because they inherit ITIL/write roles from multiple groups (e.g., itil, sn_change_write).

Even after removing all direct write roles, the inherited roles still trigger a fulfiller license.

What is the recommended best practice for downgrading such users?

[AndersBGS]

Hi @Anupam1 

I would always advise against direct role assignment and instead utilize groups to control it. You could then have a scheduled job based on last login date. If user hasn’t logged in for X days, remove them from ITIL and assign business stakeholder / nothing instead. Remember, business stakeholder also has a cost.

[Abhishek Pal]

Hi @Anupam1 ,

A user who has not logged in for 60 days is not automatically considered inactive for licensing purposes if the User record still has Active = true.

Also, removing only directly assigned write roles is not sufficient when the user continues to inherit measured roles such as itil or sn_change_write through groups or contained roles.

Recommended approach:

1. Identify the role source

Open the user record and review the Roles related list to determine whether each measured role is:

- Assigned directly
- Inherited from a group
- Inherited from another role

Do not delete inherited records directly from sys_user_has_role. Remove the source group membership or role assignment instead.

2. Remove fulfiller access at its source

For users who no longer perform fulfiller activities:

- Remove directly assigned measured roles.
- Remove them from every group granting itil, sn_change_write, or other fulfiller/write roles.
- Check for nested or contained roles that indirectly grant fulfiller access.

Removing one direct role will not reduce the entitlement while another group still grants the same or another measured role.

3. Assign the correct replacement persona

If the user only needs to view records, approve requests, review reports, or add permitted comments, assign the user through a controlled Business Stakeholder group.

Do not simply add business_stakeholder while leaving fulfiller roles in place. The remaining measured fulfiller roles can continue to determine the higher subscription requirement.

Business Stakeholder should also be used only when your organization has the required entitlement and the user's activities fall within the contracted usage rights.

4. Do not use 60 days as an automatic licensing rule

In the current Subscription Management documentation, the Active users calculation excludes users who have not logged in during the last 365 days. A 60-day internal inactivity threshold does not automatically remove their subscription entitlement.

Your contract and purchased SKU remain the authoritative source, so confirm the applicable measurement rules with your ServiceNow account team.

5. Implement a controlled access-review process

A recommended governance flow is:

Scheduled monthly review
-> Identify active users with no login for 60 or more days
-> Exclude service, integration, emergency, and approved leave accounts
-> Send review to the user's manager and group owners
-> Remove unnecessary fulfiller-group memberships
-> Assign Business Stakeholder or requester access where justified
-> Validate access and subscription usage

I would automate the review and approval process, but not automatically remove production access solely because a user has not logged in for 60 days.

6. Validate the result

After making the changes:

- Confirm the user no longer inherits any measured fulfiller role.
- Impersonate the user and verify the required read/approval access.
- Review the user under Subscription Management.
- Allow up to one daily subscription-processing cycle for the dashboard to reflect the change.

Recommended design:

Fulfiller groups
-> Users who actively create, update, fulfil, or resolve work

Business Stakeholder group
-> Users who need approved read, reporting, commenting, or approval access

Requester access
-> Users who only submit and track their own requests

Inactive/deprovisioned users
-> Set Active = false and remove operational group memberships through the normal identity lifecycle process

The key point is that the effective inherited roles determine access. Removing only direct roles does not help when the user still receives measured roles from groups.

Official references:

Managing per-user subscriptions:
https://www.servicenow.com/docs/r/platform-administration/managing-user-subscriptions-v2.html

Viewing subscription details:
https://www.servicenow.com/docs/r/platform-administration/subscription-details-v2.html

Business Stakeholder role:
https://www.servicenow.com/docs/r/it-service-management/request-management/installed-with-business-s...

User Role Inheritance API:
https://www.servicenow.com/docs/r/api-reference/rest-apis/user-role-inheritance-api.html

Because licensing terms can differ by contract and SKU, obtain written confirmation from your ServiceNow account representative before treating this as a formal license-reclamation policy.

Hope this helps!

If this response helped, please mark it as Helpful.
If it resolves your issue, please Accept it as Solution.

Kind Regards,
Abhishek Pal