While reviewing ServiceNow, I observed an inconsistency:
❌No record access
❗But row count still exposed (e.g., task)
✅Works correctly in incident
This highlights a gap between data security and metadata security.
Ex: Try this in a new Brand instance Australia version new PDI no customizations
Impersonate as end user navigate to URL : /incident_list.do?sysparm_query=stateIN1
you will see rows as zero
change URL to task level URL : /task_list.do?sysparm_query=stateIN1
You will see rows
The row count is revealed, confirming the record's existence via inference.
The Architecture Challenge: Currently, the platform lacks a centralized control for metadata/aggregate security. While I've searched Community and LinkedIn, most responses fail to offer a truly scalable solution.
⚠️Why fixing this isn’t simple
Creating Query Range ACLs at table level (table.none)
→ Needs implementation across 1k–5k tables
→ Results in massive long-term technical debt
❌Removing *.<field_name> ACLs
→ Requires full instance regression testing
→ Rebuilding specific exceptions is highly complex
❌Query Business Rules (task-level)
→ Introduces significant runtime overhead
→ Degrades performance on high-volume tables
❌Hiding row count
→ Only a superficial UI-level fix
→ Results in a confusing user experience ❌
No platform-level control exists today
~3.5K+ Query Range ACLs (*.<field_name>) already exist in many instances
Full refactor = high risk + high effort
How are you handling metadata-level security (row count / aggregates) in large-scale ServiceNow environments without adding technical debt or performance overhead?
