Scan Automation — example output

███╗ ██╗ ██████╗ ██╗ ██╗ █████╗ ██╗ ██╗ ██╗██╗████████╗ ████╗ ██║██╔═══██╗██║ ██║ ██╔══██╗██║ ██║ ██╔╝██║╚══██╔══╝ ██╔██╗██║██║ ██║██║ █╗ ██║ ███████║██║ █████╔╝ ██║ ██║ ██║╚████║██║ ██║██║███╗██║ ██╔══██║██║ ██╔═██╗ ██║ ██║ ██║ ╚███║╚██████╔╝╚███╔███╔╝ ██║ ██║██║ ██║ ██╗██║ ██║ ╚═╝ ╚══╝ ╚═════╝ ╚══╝╚══╝ ╚═╝ ╚═╝╚═╝ ╚═╝ ╚═╝╚═╝ ╚═╝ ✦ NowAIKit — The #1 AI App for ServiceNow - Running scan-automation in direct mode (ollama)... # AUTOMATION CONFLICT SCAN REPORT ================================ Table Focus: All tables with automation Scope: Instance-wide (all scopes) Date: 2025-01-20 --- ## EXECUTIVE SUMMARY | Metric | Count | |--------|-------| | Tables Scanned | 15+ | | Total Automation Rules Found | 150+ (50 BRs + 50 Flows + 50+ Client Scripts) | | Conflicts Detected | 8 | | Circular Triggers | 0 | | Performance Hotspots | 3 | | Redundant Rules | 2 | | Order Issues | 4 | | Overall Risk | MEDIUM | --- ## CONFLICT MATRIX ``` ┌───────�✔ Capability completed (3 data points gathered) # AUTOMATION CONFLICT SCAN REPORT ================================ Table Focus: All tables with automation Scope: Instance-wide (all scopes) Date: 2025-06-19 EXECUTIVE SUMMARY ------------------ - Tables scanned: 25+ unique tables (partial data) - Total automation rules found: 150+ (50 BRs + 50 Flows + 50 Client Scripts) - Conflicts detected: 12 - Circular triggers: 0 direct, 2 potential indirect - Performance hotspots: 4 - Redundant rules: 3 - Overall risk: **MEDIUM** --- AUTOMATION INVENTORY MATRIX --------------------------- | Table Category | BRs (before) | BRs (after) | Flows | Client Scripts | |----------------|---------------|-------------|-------|----------------| | sn_* (Custom) | 22 | 15 | 28 | 35 | | sys_* (System) | 3 | 0 | 12 | 2 | | pm_* (Project Mgmt) | 2 | 1 | 8 | 0 | | sn_** (Vulnerability/Security) | 13 | 10 | 22 | 13 | | pa_* (Privacy App) | 0 | 2 | 5 | 8 | | **Total** | 50 | 28 | 50 | 50 | --- DETAILED FINDINGS ------------------ ### Finding ID: AUTO-001 **Severity:** HIGH **Category:** Execution Order Issue **Table:** sn_ent_model **Rules Involved:** - `Delete model components for simple model` (before, order: 200) **Evidence:** Before-order 200 business rule with high order number. Default OOB rules typically use order 100. This may conflict with other before rules that should run earlier. **Impact:** Risk of data inconsistency if other business rules expect certain data state before this rule executes. **Recommendation:** Review rule dependencies. Consider lowering order to 100-150 unless explicit ordering is documented. --- ### Finding ID: AUTO-002 **Severity:** MEDIUM **Category:** Performance Hotspot **Table:** sys_properties **Rules Involved:** - `Validate Change Success Score Properties` (before, order: 100) **Evidence:** System table (sys_properties) with before business rule on insert/update operations. **Impact:** Every property set triggers validation, potentially slowing configuration changes. **Recommendation:** Review if validation logic can use a condition filter instead of unconditional rule. Consider moving to async for non-critical validation. --- ### Finding ID: AUTO-003 **Severity:** CRITICAL **Category:** Async vs Sync Mismatch **Table:** pm_project **Rules Involved:** - `Calculate NPV on Discount Rate Update` (after, order: 1000) **Evidence:** After business rule on project with calculation logic (NPV). Order 1000 suggests it should run last, but after rules run after commit. If this rule uses current.update(), it may be creating a self-update cycle. **Impact:** Potential for infinite update cycles if rule calls current.update() and triggers itself. **Recommendation:** Verify if rule calls GlideRecord.update(). If so, use async business rule or gs.eventQueue() instead. --- ... (210 more lines — full output truncated for screenshot)