Role-Based Access Control (RBAC) is a fundamental security mechanism in ServiceNow that governs how users interact with the platform by assigning permissions based on roles rather than individual user accounts. This approach simplifies access management and ensures that users can only view, create, modify, or delete data and functionality appropriate to their job responsibilities.

In ServiceNow, roles are defined as named collections of permissions that can be assigned to users or groups. Each role determines what tables, records, fields, and application modules a user can access. For example, the 'itil' role grants access to IT Service Management features, while the 'admin' role provides full system access.

RBac operates through several key components:

1. **Access Control Lists (ACLs):** These are security rules that define which roles are required to perform specific operations (read, write, create, delete) on tables, fields, or records. ACLs are evaluated in order from most specific to least specific.

2. **Roles:** Roles can be hierarchical, meaning one role can contain other roles. This inheritance model allows administrators to build complex permission structures efficiently.

3. **Groups:** Users are typically assigned to groups, and roles are granted to those groups. This simplifies administration since changing a group's role automatically affects all its members.

4. **User Criteria:** Beyond basic roles, ServiceNow supports user criteria to provide more granular access control based on attributes like department, location, or company.

As a Certified Application Developer, implementing proper RBAC is critical when building custom applications. Developers should create custom roles specific to their application, define appropriate ACLs for all tables and sensitive fields, follow the principle of least privilege, and avoid over-relying on the admin role.

Best practices include testing access controls thoroughly by impersonating users with different roles, documenting role assignments, and regularly auditing permissions to prevent privilege creep. Properly implemented RBAC ensures data security, regulatory compliance, and a streamlined user experience within ServiceNow applications.

Access Control Lists (ACLs) in ServiceNow are security rules that define and enforce who can access specific data and what operations they can perform on that data. They are a fundamental component of the platform's security architecture, ensuring that users only interact with records, fields, and functionalities they are authorized to use.

ACLs operate on a layered evaluation model, checking access at three levels: table, field, and record. When a user attempts to access data, the system first checks if the user has permission to access the table, then the specific record, and finally the individual fields within that record. This hierarchical approach provides granular control over data visibility and manipulation.

Each ACL rule specifies four key components: the object being secured (table, field, or record), the operation being controlled (read, write, create, or delete), the conditions under which access is granted, and the permissions required (typically role-based). ACLs can use roles, conditions, and scripts to determine whether access should be granted or denied.

ServiceNow evaluates ACLs using a most-specific-match approach. If a field-level ACL exists, it takes precedence over a table-level ACL. If no specific ACL is found, the system moves up the hierarchy to find the next applicable rule. By default, if no ACL exists for an object, access is granted — which is why proper ACL configuration is critical.

ACLs support the use of wildcard rules, allowing administrators to set broad security policies that apply across multiple tables or fields. They can also leverage advanced scripting to implement complex authorization logic based on user attributes, record values, or contextual conditions.

For application developers, understanding ACLs is essential because they must ensure their custom applications enforce proper security boundaries. Developers should follow the principle of least privilege, granting only the minimum access necessary. Properly configured ACLs protect sensitive data, maintain compliance, and ensure a secure application environment within the ServiceNow platform.

ACL (Access Control List) Rule Conditions and Scripts in ServiceNow are critical components for controlling access to data and functionality within the platform. They determine who can read, write, create, or delete records based on defined criteria.

**ACL Rule Conditions** allow administrators to set declarative conditions that must be met for access to be granted. These conditions are configured using the condition builder, which evaluates field values against specified criteria. For example, you can restrict access so that only records where the 'active' field is true are visible, or only records assigned to the current user's group are editable. Conditions are evaluated first in the ACL processing order.

**ACL Scripts** provide more advanced and flexible control when declarative conditions are insufficient. Scripts are written in server-side JavaScript and execute within the ACL evaluation context. The script must return either `true` (access granted) or `false` (access denied). Key variables available in ACL scripts include:

- **current** – the GlideRecord being evaluated
- **gs.getUser()** – provides information about the current user
- **gs.hasRole()** – checks if the user has a specific role

For example, a script might check whether the current user is the record's assignee or belongs to a specific department before granting write access.

**Evaluation Order:** ServiceNow evaluates ACL rules in a specific order — first the role requirement, then the condition, and finally the script. All three must pass (return true) for access to be granted. If any one fails, access is denied.

**Best Practices:**
1. Use declarative conditions over scripts whenever possible for better performance.
2. Keep scripts simple and efficient to minimize processing overhead.
3. Avoid using `gs.log()` or heavy queries inside ACL scripts.
4. Always test ACLs by impersonating different users to verify behavior.
5. Use the ACL debugging feature (`security.ACL.debug`) to troubleshoot.

Proper implementation of ACL conditions and scripts ensures a robust, role-based security model that protects sensitive data while maintaining usability across the ServiceNow platform.

ACL (Access Control List) Evaluation Order in ServiceNow is a critical concept for controlling access to data and functionality. Understanding how ACLs are evaluated helps developers design secure applications effectively.

When a user attempts to access a resource, ServiceNow evaluates ACLs in a specific hierarchical order, moving from the most specific rule to the most general. The evaluation follows this pattern:

1. **Match by Table and Field**: The system first checks for ACLs that match the specific table and field being accessed. For example, an ACL on 'incident.priority' is more specific and is evaluated before broader rules.

2. **Match by Table**: If no field-level ACL exists, the system looks for an ACL defined at the table level (e.g., 'incident.*'). This controls access to all fields on that table.

3. **Match by Wildcard (*)**: If no table-specific ACL is found, the system falls back to the global wildcard ACL ('*'), which applies to all tables and fields.

Within each level, ACLs are evaluated using a **most-specific-first** approach. The system also considers the operation type — read, write, create, and delete — ensuring the appropriate rule is applied for the action being performed.

**Key Evaluation Rules:**
- All matching ACLs must pass for access to be granted. ACLs are cumulative, meaning if multiple rules apply, ALL must return true.
- Each ACL rule can contain up to three evaluation criteria: a condition, a script, and a role requirement. All specified criteria within a single ACL must be satisfied.
- If no ACL rule exists for a resource, access is denied by default (when the 'high security' plugin is enabled) or granted by default in base configurations.
- Parent table ACLs are also evaluated. If a table extends another table, both the child and parent ACLs must pass.

Understanding this evaluation order ensures developers create precise, layered security rules that protect sensitive data while maintaining usability for authorized users. Proper ACL design minimizes conflicts and avoids unintended access issues.

In ServiceNow, Access Control Lists (ACLs) are critical security mechanisms that govern who can access data and what operations they can perform. Two fundamental types are Table-Level and Field-Level ACLs, each serving distinct purposes in restricting access.

**Table-Level ACLs** control access to an entire table and its records. They define whether a user can read, write, create, or delete records within a specific table. For example, a Table-Level ACL on the Incident table might restrict the 'delete' operation so only users with the 'admin' role can delete incident records. When a user attempts to access any record in the table, ServiceNow evaluates the table-level ACL first. If the user fails this check, they are denied access to the entire table, and field-level checks are not even evaluated.

**Field-Level ACLs** provide more granular control by restricting access to specific fields within a table. Even if a user has table-level read access to the Incident table, a field-level ACL can prevent them from viewing or editing sensitive fields like 'assignment_group' or 'priority.' This allows administrators to show or hide individual fields based on roles, conditions, or scripts.

**Evaluation Order:** ServiceNow evaluates ACLs in a hierarchical manner. It first checks table-level ACLs, then field-level ACLs. A user must pass both levels to access a specific field. If no field-level ACL exists, the table-level ACL permissions apply by default.

**Key Differences:**
- **Scope:** Table-level applies to all records and fields; field-level targets specific fields.
- **Granularity:** Field-level offers finer control over data visibility and editability.
- **Use Case:** Table-level is ideal for broad access restrictions, while field-level is used for protecting sensitive data within otherwise accessible tables.

**Best Practice:** Always define table-level ACLs first to establish baseline security, then layer field-level ACLs for additional restrictions. This defense-in-depth approach ensures comprehensive data protection across your ServiceNow applications.

ACL Debugging in ServiceNow is a powerful diagnostic tool that allows developers and administrators to troubleshoot and understand how Access Control Lists (ACLs) are being evaluated when users attempt to access records, fields, or operations within the platform.

When enabled, ACL Debugging provides detailed information about which ACL rules are being checked, whether they pass or fail, and the order in which they are evaluated. This is essential for identifying why a user may or may not have access to specific resources.

To enable ACL Debugging, navigate to the System Security module and activate the debugging session. You can also enable it by setting the 'glide.security.debug' system property to true, or by using the session-level debug option via 'System Diagnostics > Session Debug > Debug Security'. Once activated, the system outputs detailed security evaluation logs in the session debug output or system logs.

The debug output typically includes the following information: the table and field being accessed, the operation type (read, write, create, delete), the specific ACL rule being evaluated, whether the ACL passed or failed, the conditions and scripts within the ACL, and the evaluation order based on ACL specificity.

ServiceNow evaluates ACLs in a specific order of specificity: table.field, table.*, and then *.* (wildcard). The most specific rule matching the request is evaluated first. All applicable ACL rules must pass for access to be granted.

Key best practices for ACL Debugging include: enabling it only during troubleshooting sessions to avoid performance impacts, reviewing both condition-based and script-based ACL evaluations, checking for inherited ACLs from parent tables, and ensuring you disable debugging after completing your investigation.

ACL Debugging is invaluable during application development to verify that security rules are functioning as intended, ensuring users have appropriate access levels while maintaining data security. It helps developers quickly pinpoint misconfigured rules and resolve access-related issues efficiently within the ServiceNow platform.

GlideSystem Security Methods in ServiceNow are a set of server-side API methods available through the 'gs' (GlideSystem) object that help developers manage and enforce security within applications. These methods are essential for controlling access, validating user permissions, and ensuring data security across the platform.

**Key Methods Include:**

1. **gs.hasRole('role_name')** - This is one of the most commonly used security methods. It checks whether the currently logged-in user has a specific role. It returns true or false, allowing developers to conditionally execute logic based on role assignments. Admin users typically return true for all role checks.

2. **gs.hasRoleExactly('role_name')** - Unlike hasRole(), this method checks if the user has the exact role specified, without considering admin overrides. This is useful when you need strict role validation, even excluding admin users from bypassing the check.

3. **gs.hasRoleInGroup('role_name', 'group_sys_id')** - Verifies whether a user has a specific role within a particular group. This provides more granular security control by combining role and group membership checks.

4. **gs.getUser()** - Returns a GlideUser object representing the current user, which provides additional methods to check roles, group memberships, and user attributes.

5. **gs.getUserID()** - Returns the sys_id of the currently logged-in user, useful for querying records related to the current user.

6. **gs.isLoggedIn()** - Checks whether a user is currently authenticated in the system.

7. **gs.isInteractive()** - Determines if the current session is interactive (browser-based) versus a background script or scheduled job.

**Practical Applications:**

These methods are commonly used in Business Rules, Script Includes, UI Actions, and Access Control Lists (ACLs) to enforce security policies. For example, a Business Rule might use gs.hasRole() to prevent non-admin users from modifying critical records. Developers use these methods to implement defense-in-depth strategies, ensuring multiple layers of security protect sensitive data and operations within ServiceNow applications.

Application Scope Security in ServiceNow is a fundamental mechanism that controls how applications interact with each other and protects application data, logic, and resources from unauthorized access or modification. When developing applications in ServiceNow, each application is assigned a unique scope that acts as a namespace and security boundary.

Application scopes ensure that one application cannot directly access or modify the tables, scripts, and configurations of another application without explicit permission. This is critical in environments where multiple applications coexist on a single ServiceNow instance, including custom-built and third-party applications.

There are two primary types of application scopes: **Global Scope** and **Private (Scoped) Scope**. The Global scope is the default scope and has broad access across the platform. Private scoped applications, however, operate within strict boundaries and must request cross-scope access through defined privileges.

Key aspects of Application Scope Security include:

1. **Cross-Scope Access Policies**: These define whether external applications can read, write, create, or delete records in a scoped application's tables. Developers can configure these policies to allow or restrict access explicitly.

2. **Scripting Restrictions**: Scripts running within a scoped application can only access their own APIs and resources by default. To interact with resources outside their scope, they must use proper API calls and have the necessary cross-scope privileges granted.

3. **Protection Policies**: Developers can protect their application artifacts (such as scripts, tables, and business rules) from being modified by administrators or other developers by setting runtime and design-time protection policies.

4. **Application Access Configuration**: In the application record, developers can configure settings like 'Accessible from all scopes' or restrict access to specific callers, providing granular control over who can interact with the application.

Application Scope Security is essential for maintaining data integrity, enforcing separation of concerns, and ensuring that applications function independently without unintended interference. It supports a secure multi-application architecture and is a key topic for the Certified Application Developer exam.

User Criteria in ServiceNow is a powerful mechanism used to control and restrict access to specific resources, content, and functionalities within the platform. It defines a set of conditions that determine which users can access particular items such as Knowledge Bases, Service Catalog items, and Service Portal pages.

User Criteria works by evaluating users against defined conditions based on various attributes, including:

1. **Users**: Directly specifying individual users who meet the criteria.
2. **Groups**: Targeting members of specific groups.
3. **Roles**: Filtering users based on assigned roles.
4. **Department**: Matching users by their department.
5. **Location**: Filtering based on user location.
6. **Company**: Restricting access by company affiliation.
7. **Script-based Conditions**: Advanced criteria using scripts for complex evaluations.

User Criteria can be applied in two primary ways:

- **Available For (Positive Criteria)**: Defines who CAN access the resource. Only users matching the criteria will have access.
- **Not Available For (Negative Criteria)**: Defines who CANNOT access the resource. Users matching this criteria will be explicitly denied access.

When both positive and negative criteria are applied, the negative criteria (Not Available For) takes precedence over positive criteria. This means if a user matches both, they will be denied access.

Key use cases include:
- Restricting Knowledge Base articles to specific departments or roles
- Limiting Service Catalog items visibility to certain groups
- Controlling Service Portal widget and page access
- Managing content availability across different user segments

User Criteria records are reusable, meaning once created, they can be applied across multiple resources, promoting consistency and reducing administrative overhead. They are stored in the `user_criteria` table and can be managed through the User Criteria module in the navigator.

This approach provides a flexible, maintainable, and granular access control layer that complements ServiceNow's role-based access control (ACLs), enabling administrators and developers to deliver personalized and secure user experiences without modifying underlying security rules.

Data Policies in ServiceNow are powerful mechanisms used to enforce data consistency and integrity across the platform, ensuring that critical fields meet specific requirements regardless of how data enters the system. Unlike UI Policies, which only apply to forms viewed through the standard browser interface, Data Policies enforce rules across all access points, including web services, import sets, direct API calls, and the standard UI.

Data Policies allow administrators to set fields as mandatory, read-only, or visible/hidden based on defined conditions. When a Data Policy is configured, it validates data at the server level, meaning that even if a record is created or modified through an integration or script, the policy will still be enforced. This makes Data Policies essential for maintaining security and data quality.

Key features of Data Policies include:

1. **Cross-Platform Enforcement**: They apply to all data entry methods, not just the browser-based UI, ensuring consistent validation across inbound integrations, APIs, and import sets.

2. **Mandatory Fields**: Administrators can require that specific fields contain values before a record can be saved, preventing incomplete data entries.

3. **Read-Only Fields**: Certain fields can be locked to prevent unauthorized modifications, protecting sensitive data from being altered.

4. **Conditional Logic**: Data Policies can be configured with conditions, so rules only apply when specific criteria are met, providing flexibility in enforcement.

5. **UI Policy Integration**: When the 'Apply to import sets' or 'Apply to SOAP' checkboxes are enabled, the policy extends beyond the UI. Additionally, checking 'Use as UI Policy on client' allows the Data Policy to mirror its behavior on the client side.

From a security perspective, Data Policies are critical because they prevent bypassing of validation rules through alternative data entry channels. They complement Access Control Lists (ACLs) and Business Rules to create a layered security approach, ensuring that data integrity is maintained while restricting unauthorized or invalid data modifications across the entire ServiceNow platform.

Contextual Security in ServiceNow refers to the practice of dynamically controlling access to data, UI elements, and functionality based on the current user's context, such as their roles, group memberships, and session attributes. Two of the most commonly used server-side APIs for implementing contextual security are gs.hasRole() and gs.getUser().

**gs.hasRole(roleName):**
This GlideSystem method checks whether the currently logged-in user has a specific role. It returns a boolean value — true if the user possesses the role, false otherwise. For example, gs.hasRole('admin') returns true if the current user has the admin role. This method is widely used in Business Rules, Script Includes, UI Actions, and ACLs to conditionally execute logic based on role assignments. It respects role inheritance, meaning if a user has a parent role that includes the checked role, it will still return true.

**gs.getUser():**
This method returns a GlideUser object representing the currently logged-in user. The GlideUser object provides several useful methods such as getID() (returns sys_id), getUserName() (returns username), getFirstName(), getLastName(), isMemberOf(groupSysId), and hasRole(roleName). This allows developers to make fine-grained security decisions based on user attributes beyond just roles.

**Practical Applications:**
- **Business Rules:** Restrict record updates so only users with specific roles can modify certain fields.
- **UI Actions:** Conditionally show or hide buttons based on user roles using conditions like gs.hasRole('itil').
- **ACL Scripts:** Enhance Access Control Lists with scripted conditions that check user context.
- **Client-callable Script Includes:** Validate that the calling user has appropriate permissions before returning sensitive data.

**Best Practices:**
- Always use contextual security checks in server-side scripts, as client-side checks can be bypassed.
- Combine role checks with ACLs for defense-in-depth.
- Avoid hardcoding user sys_ids; use roles and groups instead for maintainability.
- Use gs.hasRole() sparingly and prefer ACLs for standard access control to keep security manageable and auditable.

Contextual security ensures that application behavior adapts securely to each user's permissions and identity.