Row-Level Security Pattern Implementation

advancedTested on Xanadu

The Row-Level Security pattern provides fine-grained access control by filtering database queries at the record level before data is retrieved. This pattern ensures users only see records they are authorized to access based on their attributes, group memberships, location, or other business criteria, rather than relying solely on table-level ACLs.

This pattern works by implementing before-query business rules that automatically append encoded query conditions to incoming database queries. The business rule examines the current user's context and applies appropriate filters transparently, ensuring consistent security enforcement across all access methods including lists, forms, reports, and API calls.

The pattern is particularly powerful because it operates at the GlideRecord query level, meaning it protects data regardless of how it's accessed - through the UI, web services, or integrations. It provides defense-in-depth by adding an additional security layer that complements existing ACL and role-based security mechanisms.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Use This When

Use this pattern when you need to enforce data segregation within a single table based on user attributes, such as restricting sales representatives to see only their assigned accounts, limiting HR personnel to employee records in their region, or ensuring multi-tenant applications properly isolate customer data. This pattern is ideal for compliance requirements that mandate strict data access controls and audit trails.

Avoid When

Avoid this pattern for simple read/write permissions that can be handled by standard ACLs, as it adds query overhead and complexity. Don't use it when the filtering logic is extremely complex or requires joins across multiple tables, as this can significantly impact database performance and make troubleshooting difficult.

Implementation

Server-side

// Business Rule: Row Level Security for Incident Table
// Table: incident
// When: before
// Order: 100
// Filter Conditions: empty (runs on all queries)
// Advanced: true

(function executeRule(current, previous) {
    // Skip if running as admin or system user to avoid infinite loops
    if (gs.hasRole('admin') || gs.getUserID() === 'system') {
        return;
    }
    
    // Get current user's attributes
    var userGR = new GlideRecord('sys_user');
    userGR.get(gs.getUserID());
    var userLocation = userGR.getValue('location');
    var userDepartment = userGR.getValue('department');
    
    // Build security filter based on user context
    var securityFilter = '';
    
    // Location-based filtering
    if (userLocation) {
        securityFilter += 'caller_id.location=' + userLocation;
    }
    
    // Department-based filtering for HR group members
    if (gs.getUser().isMemberOf('hr_users')) {
        if (securityFilter) securityFilter += '^OR';
        securityFilter += 'caller_id.department=' + userDepartment;
    }
    
    // Manager access - can see direct reports' incidents
    var directReports = getDirectReports(gs.getUserID());
    if (directReports.length > 0) {
        if (securityFilter) securityFilter += '^OR';
        securityFilter += 'caller_idIN' + directReports.join(',');
    }
    
    // Apply the security filter to the current query
    if (securityFilter) {
        current.addEncodedQuery(securityFilter);
        gs.log('Row-level security applied for user ' + gs.getUserName() + ': ' + securityFilter, 'RowLevelSecurity');
    }
    
    // Helper function to get direct reports
    function getDirectReports(managerId) {
        var reports = [];
        var userGR = new GlideRecord('sys_user');
        userGR.addQuery('manager', managerId);
        userGR.addQuery('active', true);
        userGR.query();
        
        while (userGR.next()) {
            reports.push(userGR.getUniqueValue());
        }
        return reports;
    }
})(current, previous);

This business rule executes before every query on the incident table and dynamically adds encoded query filters based on the user's location, department, and management hierarchy. The rule skips admin users to prevent infinite loops and uses addEncodedQuery() to append security conditions that limit record visibility. Key aspects include checking user group membership for role-based filtering and building complex OR conditions to handle multiple access scenarios.

Alternatives

Domain Separation

Use domain separation when you need complete data isolation with hierarchical inheritance. It provides stronger separation but requires Enterprise licensing and can be complex to implement across custom applications.

ACL with Script Conditions

Implement ACLs with advanced script conditions when you need operation-specific security (read vs write vs delete). ACLs are easier to manage and debug but operate at the table level and may not provide the granular record-level control needed for complex scenarios.

Custom GlideRecord Wrapper

Create a Script Include wrapper around GlideRecord queries when you need centralized security logic that can be selectively applied. This provides more control but requires discipline to use consistently and doesn't protect against direct GlideRecord usage.

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue