No records to display when user applied the filter on Risk Event Tasks table

[Majji Koteswar1]

Hi Team,

As an admin, I got the records if I apply the filter (Risk Event (sn_risk_advanced_event)-> "Date first moved to approved" (custom field) relative before 180 Days ago) on Risk Event Tasks (sn_risk_advanced_mitigation_task) table. But as a Risk Manager, it says no records to display. If the user applies the filter ("Date first moved to approved" relative before 180 Days ago) directly on Risk Events then it displays the records.

User access was validated using the access permissions module. He cleared all checks including query range ACLs, and no restricting query business rules were identified.

Please advice on additional steps that can be taken to determine the root cause.

Thanks,

Majji

[Aditya_hublikar]

Hello @Majji Koteswar1 ,

Im not pretty sure about this isuue but it may occur due to ACL . This issue may occurs due to missing field-level read access on a dot-walked field. While an Admin can see the records because Admin users bypass all ACLs, the Risk Manager cannot see any records when filtering Risk Event Tasks using the condition Risk Event → Date first moved to approved (relative before 180 days). Even though the Risk Manager has access to both the Risk Event and Risk Event Task tables, and no restricting query business rules or Access Permissions failures are found, ServiceNow still enforces field-level ACLs on the referenced Risk Event field during a dot-walk query. Since the Risk Manager does not have read access to the Date first moved to approved field on the Risk Event table, the query silently returns no records. This is why the same filter works when applied directly on the Risk Event table but fails when used from Risk Event Tasks. Granting read access to this field for the Risk Manager role on the Risk Event table resolves the issue.

If this helps you then mark it as helpful and accept as solution.

Regards,

Aditya

[AnkaRaoB]

Hi @Majji Koteswar1 ,

When a dot-walked filter returns results for admin but not for a Risk Manager, the most common cause is missing read access to the dot-walked field. Even if the user can access both tables individually, ServiceNow requires read access to every table and field involved in the dot-walk for the filter to evaluate. Enabling Security Debug while impersonating the user usually reveals the denying ACL.

If my response helped mark as helpful and accept the solution

[Ankur Bawiskar]

@Majji Koteswar1 

share your screenshots