how to troubleshoot dormant account report showing active users error in access review

Not specified by the original author.

TL;DR

Fix the report definition before you act on its output, because removing access for active users is the worst outcome a review can produce. List the activity signals the report counts, such as sign-in logs, key usage or application activity, and check the lookback window and the timezone or filter it applies. Test the report logic against five users whose activity you can prove from raw logs, correct the signal or window that misclassifies them, and rerun the full report only when the sample classifies correctly.

how to troubleshoot dormant account report showing active users error in access review

Use this when

• Users who signed in this week appear on the dormant or inactive list.
• Whole teams with daily application use are flagged as dormant.
• The dormant count jumped after a report or tool change.

Not for this skill when

• The flagged users truly have no activity in any system. Proceed with the dormant account process instead.
• Sign-in logs themselves are missing. Fix log collection before fixing the report.

Steps

1. Pick five flagged users and pull their raw sign-in or activity records from the source logs for the report window, saving proof of their latest activity dates. Verify: each sampled user has a proven last activity date from raw logs.
2. Open the report definition and list every activity signal it uses, its lookback days and any filters on user type, licence or group that could exclude real activity. Verify: the report logic is written down in full.
3. Compare the sampled proof with the report classification and identify the exact mismatch, such as a window that ends before the proof dates or a signal the users activity never generates. Verify: the misclassifying element is named.
4. Correct the definition, for example extending the window, adding the application activity signal or including service and API activity where the population legitimately uses it. Verify: the corrected definition is saved as a new report version.
5. Rerun the report for the sampled users only, or a small department, and confirm all five now classify according to their proven activity. Verify: the sample classifies correctly against the raw log proof.
6. Run the full report, compare its dormant count with the previous run, and sanity check the change with the team that owns the population before any removal actions start. Verify: the new count is explained by the definition change and accepted by the owner.
7. Version and date the corrected definition in the review evidence so future cycles can tell which logic produced which list. Verify: the evidence names the report version used for decisions.

Why it happens

Dormancy is a derived judgement, not a raw fact. A report assembles it from whichever activity signals it was built with, and populations whose real work happens through an API, a shared integration or an application that does not write sign-in logs can look idle to a sign-in only report. Window boundaries and filters quietly exclude more activity still. Validating against raw logs for a small proven sample is the fastest way to find which assumption is wrong before the report drives removals at scale.

Variants and edge cases

inactive users report includes active employees

The false positive phrasing. Always validate a sample against raw logs before any access is touched.

dormant account detection using wrong last logon

The field phrasing. Some directories keep several last activity fields that update differently; confirm which one the report reads.

access review flags users who use API only access

The API phrasing. Add key or client usage signals for populations that never sign in interactively.

Edge cases to check before closing the review cycle:

• A user can be active in one system and dormant in the one under review. Keep dormancy scoped per application, not global, unless policy says otherwise.
• Log retention shorter than the lookback window guarantees false dormancy. Align the window with actual retention.
• Seasonal staff will always look dormant off season. Tag known seasonal populations instead of re-litigating them each cycle.

Compatibility: Access review dormancy reports in Entra ID, Okta and custom tooling, sign-in and activity logs, IAM credential usage data.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstahX4lRy1wr6B_kjSjl29Q

Resolved from the public thread: https://vectle.com/posts/pstahX4lRy1wr6B_kjSjl29Q

Thread query: how to troubleshoot dormant account report showing active users error in access review

TL;DR: Fix the report definition before you act on its output, because removing access for active users is the worst outcome a review can produce. List the activity signals the report counts, such as sign-in logs, key usage or application activity, and check the lookback window and the timezone or filter it applies. Test the report logic against five users whose activity you can prove from raw logs, correct the signal or window that misclassifies them, and rerun the full report only when the sample classifies correctly.