---
name: nowdev-ai-toolbox-access-denied-explainer
user-invocable: true
description: Explains exactly why a ServiceNow user lacks access or permissions to view/edit a record, view/modify a field, or execute an action/UI Action, and provides a precise remedy. Triggers when the user mentions "I can't see/edit X", "insufficient rights", "why is this field read-only", "access denied", "user can't run this action/UI action", "ACL failure", "no write access", "cannot view", or similar permission and access restriction issues. It uses read-only `now-sdk` retrieval delegated to `nowdev-ai-toolbox-servicenow-sdk` to trace ACL evaluations and identify failing roles or conditions.
argument-hint: "[table.field] [user] [operation]"
---

# ServiceNow Access Denied Explainer

This skill provides a structured, live diagnostic tracing workflow to analyze, diagnose, and resolve access control list (ACL) failures and security permission issues on a ServiceNow instance (e.g., why a user gets "Access Denied", why a field is unexpectedly read-only, or why a record is hidden).

---

## Core Principles

1. **Strictly Read-Only:** NEVER perform write, update, delete, or credential-mutating operations on the instance. Use `now-sdk` only for read-only retrieval of structural information and roles.
2. **SDK Authority:** Load `nowdev-ai-toolbox-servicenow-sdk` before using `now-sdk`. It is the sole authority for command construction, flags, authentication aliases, output handling, pagination, and CLI troubleshooting.
3. **Deterministic Evaluation Trace:** Reconstruct ServiceNow's multi-tier ACL evaluation logic (Table-level security checks first, then Field-level check; check roles first, then evaluate condition and script criteria).
4. **No Direct Security Alteration:** Provide clear recommendations and exact snippets describing how to grant or modify permissions, but do not execute changes.

---

## Standard Diagnosing Workflow

Follow these steps precisely when diagnosing an access issue:

### Step 1: Identify Context & Scopes
1. **Identify Target Table & Field:** Determine the ServiceNow table (e.g., `incident` or `x_abc_app_my_table`) and the specific field (e.g., `short_description`) being accessed.
2. **Identify Operation:** Determine the requested operation: `read`, `write`, `create`, `delete`, or `execute`.
3. **Identify User Context:** Identify the target user. If a name or sys_id is provided, search for them. If none is listed, check if the current user context or default admin/agent needs to be evaluated.
4. **Identify Target Instance:** Determine the intended connected instance. Delegate alias discovery and selection mechanics to `nowdev-ai-toolbox-servicenow-sdk`; if the target is ambiguous, ask the user before retrieval.

---

### Step 2: Retrieve Live Instance Data
Ask `nowdev-ai-toolbox-servicenow-sdk` to perform bounded, read-only retrievals from the intended instance using this specification. Resolve reference display names when needed for role analysis; the canonical SDK skill decides the CLI mechanics.

| Table | Filter intent | Fields | Limit intent |
|---|---|---|---|
| `sys_user` | Match the supplied username, email, or known `sys_id` | `sys_id,name,active` | One exact user |
| `sys_user_has_role` | Active role grants for the affected user | `role,inherited,user` | All matching grants needed to establish direct roles |
| `sys_user_grmember` | Memberships for the affected user | `group,user` | All matching memberships needed for inheritance tracing |
| `sys_group_has_role` | Roles for the discovered group IDs | `role,group,inherits` | All matching role mappings for those groups |
| `sys_security_acl` | Active ACLs for the requested operation matching the target table, parent tables, and table wildcards such as `<table>`, `<table>.None`, and `*.None` | `sys_id,name,operation,active,advanced,script,condition,admin_overrides,type` | All applicable ACLs; paginate deliberately if the bounded response is incomplete |
| `sys_security_acl` | Active ACLs for the requested operation matching the exact field, parent-table field, and wildcard patterns such as `<table>.<field>`, `<table>.*`, `*.<field>`, and `*.*` | `sys_id,name,operation,active,advanced,script,condition,admin_overrides,type` | All applicable field ACLs; paginate deliberately if needed |
| `sys_security_acl_role` | ACL reference is in the discovered ACL ID set | `sys_id,sys_security_acl,sys_user_role` | All role mappings for the discovered ACLs |

---

### Step 3: Evaluate security rules & Trace failures
Once the data is retrieved, construct the evaluation tracing log:
1. **Aggregate User's Roles:** Build a unique set of all role display names (direct and group-inherited) belonging to the user.
2. **Execute Table-Level ACL Evaluation:**
   - Filter active ACLs targeting the table directly (e.g. `table` or `table.None` or `*.None`).
   - If multiple active ACLs match: **At least one ACL must pass (logical OR)** for table access.
   - For each matching ACL:
     - **Role Requirements Check:** Does the user have at least one of the roles mapped to this ACL in `sys_security_acl_role`? (If no roles are mapped to an ACL, it does not require a role, passing this step automatically).
     - **Condition Check:** Does the record/context satisfy the ACL's `condition`?
     - **Script Check:** Does the `script` evaluate to true?
     - If all three items (Roles AND Condition AND Script) match, this ACL passes.
   - If no table-level ACL passes, the operation fails at the table boundary.
3. **Execute Field-Level ACL Evaluation:**
   - Only execute this if table-level evaluation passed.
   - Map field-specific ACLs in order of specificity: `table.field` → `parent_table.field` → `*.field` → `table.*` → `parent_table.*` → `*.*`.
   - Each level must pass. If a matching ACL is found, the user must satisfy its configuration (Roles AND Condition AND Script).
   - If any applicable field-level constraint is failed, the operation fails.

---

### Step 4: Formulate the Explanation Report
Generate a detailed diagnostic report in the user's language containing the precise reasons and recommendations.

---

## Report Structure

When responding to the user, you must ALWAYS structure your output using the following layout (translated to the user's active language if non-English):

# 🔍 Access Diagnostic Report
**Affected User:** `[User Display Name or Sys ID]`
**Target Table/Element:** `[Table / Field Name]`
**Current Operation:** `[read / write / create / delete]`

---

## 🚦 Security Audit Summary
- **Verdict:** `[ACCESS GRANTED / ACCESS DENIED - Fail at Table-level / ACCESS DENIED - Fail at Field-level]`
- **Root Cause Summary:** `[Brief, concise sentence explaining exactly why the access was denied, e.g., "The user lacks the 'itil' role required by the table-level read ACL."]`

---

## 🧬 ACL Evaluation Trace
Construct a sequence showing which security rules were checked and their outcome:

| ACL Sys ID | Target/Name | Required Role(s) | Condition / Script Check | Status |
|---|---|---|---|---|
| `[Sys ID]` | `[e.g., incident.None]` | `[Required Roles list]` | `[Checked / Passed / Failed]` | `[❌ Fail (Role Missing) / Check condition / etc.]` |
| `[Sys ID]` | `[e.g., incident.short_description]` | `[Required Roles list]` | `[Checked / Not run]` | `[Skipped (Table-level failed)]` |

*(Clearly list all matching ACLs found and mark which evaluated first, and what failed).*

---

## 👥 Affected User's Active Roles
List the roles held by the target user that were discovered during evaluation:

- **Directly Assigned Roles:** `[comma-separated list of direct roles]`
- **Group-Inherited Roles:** `[comma-separated list of group-inherited roles and the groups they came from]`

---

## 🛠️ Recommended Corrective Actions
Provide technical, actionable, read-only remedies. Provide the exact path and sys_id of rules to adjust or roles to assign:

- **Action Option A (Grant User Privilege):** Assign the missing role (`[role_name]`) to the user directly, or add them to the assignment group `[group_name]` which inherits the role. This is the recommended secure pattern.
- **Action Option B (Modify ACL Rule):** Adjust the ACL script or conditions under `sys_security_acl.do?sys_id=[acl_id]` to allow the action.

---

## Language Alignment / Multilingual Support

- **ALWAYS** communicate with the user, draft the Access Diagnostic Report, and formulate response summaries in the exact language used by the user in their active prompt or conversation context.
- Translate standard layout headers appropriately so the report remains fully aligned and native to the user's language (e.g., in Spanish: `# 🔍 Reporte de Diagnóstico de Acceso` instead of `# 🔍 Access Diagnostic Report`, `## 🚦 Resumen de Auditoría de Seguridad` instead of `## 🚦 Security Audit Summary`, etc.).
- **Technical Safeguard:** KEEP technical system strings, ServiceNow table names (e.g., `sys_security_acl`), field names (e.g., `sys_updated_by`), role names (e.g., `itil`), Sys IDs, and filter intent in technical English to preserve precision.