Merge branch 'ServiceNowDevProgram:main' into attaching-attachment-to-record

Author: chaitanyalal18

Server-Side Components/Business Rules/Automatically Populate Incident with Work Order Number/Populate_WorkOrder_Number_1.png

@@ -0,0 +1,60 @@
+# Automatically Populate Incident with Work Order Number, State , OnHold Reason using business rule
+
+This use case automates the linkage between **Work Orders** and **Incidents** in ServiceNow. When a **Work Order** is created from an **Incident**, the system automatically :
+- Populates the Work Order reference (**u_work_order**) field on the parent Incident  
+- Sets the **Incident State → On Hold**  
+- Updates the **Hold Reason → Awaiting Field Work Order**  
+- Adds a **work note** in the Activity Stream for traceability  
+
+This ensures a seamless connection between **ITSM** and **Field Service Management (FSM)** processes, allowing  to identify related Work Orders without navigating to related lists.
+
+## Why This Use Case
+Out-of-the-box (OOB) ServiceNow does **not** include a direct Work Order reference field on the Incident form.  
+By default, users can only view Work Orders under the *Related Tasks → Work Orders* section, which limits quick visibility.  
+
+To address this gap, a custom reference field (**u_work_order**) was created under the **Related Records** section ( similar to *Problem* or *Parent Incident* ).  
+- Displays the linked Work Order number directly on the Incident form    
+- Prevents manual modification while maintaining clear visibility for agents  
+
+## Process Alignment
+In standard ITSM workflows, Incidents can be placed **On Hold** for reasons such as *Awaiting Problem*, *Awaiting Change*, or *Awaiting Vendor*.  Since there was no default option for Field Service, this customization introduces a new Hold Reason : **Awaiting Field Work Order**
+
+When a Work Order is created from an Incident:
+- The Incident automatically moves to **On Hold**  
+- The **Hold Reason** updates to *Awaiting Field Work Order*  
+- A **work note** logs the Activity Stream  
+
+This behavior aligns with existing ITSM hold logic for Problem and Change processes
+
+## Prerequisites
+
+#### Ensure FSM Application Plugin is Installed
+- This customization requires the Field Service Management (FSM) plugin to be installed and active in ServiceNow instance  
+- Search for Field Service Management plugin **com.snc.work_management** and install
+- FSM provides the **Work Order [wm_order]** table
+  
+#### Create a Custom Field on the Incident Table
+- Create Custom Reference Field on Incident table with label name **Work Order** [u_work_order] and select Type as **Reference**   
+- Reference to Table Work Order [wm_order]  
+- Save and add this field to the **Incident form** under the **Related Records** section
+
+#### Add Custom Choice in On Hold Reason Field
+- Navigate to hold_reason field on Incident table
+- Configure dictionary and add **Awaiting Field Work Order** with value set as 2 and sequence as 5  
+- Save the new choice to make it selectable in the *Hold Reason* field.
+
+---
+### Creating an Incident
+![Create_Incident](Populate_WorkOrder_Number_1.png)
+
+---
+
+### Work Order Created from Incident
+![WorkOrder_From_Incident](Populate_WorkOrder_Number_2.png)
+
+---
+
+### Incident Updated with Work Order Reference, State On Hold, and Reason Awaiting Field Work Order
+![Populate_WorkOrderNumber_State_onHoldReason](Populate_WorkOrder_Number_3.png)
+
+

Server-Side Components/Business Rules/Automatically Populate Incident with Work Order Number/Populate_WorkOrder_Number_2.png

@@ -0,0 +1,22 @@
+(function executeRule(current, previous /*null when async*/) {
+
+    if (!current.initiated_from.nil()) {
+
+        var inc = new GlideRecord('incident');
+        if (inc.get(current.initiated_from)) {
+
+            // Link the Work Order reference to the Incident
+            inc.u_work_order = current.sys_id;
+
+            // Move the Incident to On Hold and set Hold Reason
+            inc.state = 3;                 // 3 = On Hold
+            inc.hold_reason = '2';         // Awaiting Field Work Order (custom choice value created)
+
+            // Add work note 
+            inc.work_notes = 'Work Order ' + current.number + ' has been created and Incident moved to On Hold.';
+
+            inc.update();
+        }
+    }
+
+})(current, previous);

Server-Side Components/Business Rules/Automatically Populate Incident with Work Order Number/Populate_WorkOrder_Number_3.png

@@ -0,0 +1,8 @@
+Scheduled Script Execution: Auto-cancel RITM if group manager approval pending after 30 days
+
+This script:
+- Finds RITM records older than 30 days
+- Checks if any group manager approvals are still pending (state='requested')
+- If so, cancels the RITM (sets state to 'Cancelled')
+Usage:
+- Schedule this script to run daily.

Server-Side Components/Business Rules/Automatically Populate Incident with Work Order Number/README.md

@@ -0,0 +1,38 @@
+/*
+Scheduled Script Execution: Auto-cancel RITM if group manager approval pending after 30 days
+
+This script:
+- Finds RITM records older than 30 days
+- Checks if any group manager approvals are still pending (state='requested')
+- If so, cancels the RITM (sets state to 'Cancelled')
+Usage:
+- Schedule this script to run daily.
+*/
+
+// Calculate date 30 days ago
+var thirtyDaysAgo = new GlideDateTime();
+thirtyDaysAgo.addDaysUTC(-30);
+
+// Query RITMs older than 30 days and not closed/cancelled already
+var ritmGR = new GlideRecord('sc_req_item');
+ritmGR.addQuery('sys_created_on', '<=', thirtyDaysAgo);
+ritmGR.addEncodedQuery('stateIN1,2,112^cat_item=a24b1e113bc21e1050109c9c24e45a51');
+ritmGR.query();
+
+while (ritmGR.next()) {
+    // Query approvals for this RITM from group managers - adjust condition accordingly
+    var approvalGR = new GlideRecord('sysapproval_approver');
+    approvalGR.addQuery('sysapproval', ritmGR.sys_id); // approvals linked to this RITM
+    approvalGR.addQuery('state', 'requested'); // pending approvals
+    approvalGR.query();
+
+    if (approvalGR.hasNext()) {
+        // Group manager approvals pending after 30 days => Cancel RITM
+		
+        ritmGR.state = 8; // Closed Cancelled
+		ritmGR.assignment_group = '<assignment_group_name or sysid>'; //group ABC
+        ritmGR.work_notes = 'Auto-cancelled due to no group manager approval within 30 days.';
+        ritmGR.update();
+
+    }
+}

Server-Side Components/Business Rules/Automatically Populate Incident with Work Order Number/businessRuleFsmUsecase.js

@@ -0,0 +1,4 @@
+This script will identify all the retired CI and update the releationship by removing it from the CIs
+ This is will query the cmdb_ci_rel table and fetch all ci with status as install status == 7 and parent install status == 7
+
+ As result it will delete all CI relationship and update the delete entry by querying custom table u_deleteret_app

Server-Side Components/Scheduled Jobs/CancelApproval/readme.md

@@ -0,0 +1,19 @@
+//get all relationship records where retired CI is Parent
+var gr = new GlideRecord('cmdb_rel_ci');
+gr.addEncodedQuery("child.install_status=7^ORparent.install_status=7");
+gr.query();
+
+//For each record with a retired CI
+while (gr.next()) {
+    var par = gr.parent;
+    var child = gr.child;
+    var tp = gr.type;
+    gr.deleteRecord();
+
+    var gr1 = new GlideRecord('u_delete_retired_relationships');
+    gr1.initialize();
+    gr1.u_child = child;
+    gr1.u_parent = par;
+    gr1.u_type = tp;
+    gr1.insert();
+}

Server-Side Components/Scheduled Jobs/CancelApproval/script.js

@@ -0,0 +1,68 @@
+# Attachment Downloads Logger
+
+A ServiceNow utility that logs attachment download activities by adding comments to the work notes of the associated record, enhancing visibility and ensuring compliance.
+
+## Challenge
+
+Tracking attachment downloads in ServiceNow can be critical for maintaining data security and compliance. Without proper logging, it becomes difficult to identify who accessed sensitive information and when. This utility addresses this challenge by providing an automated solution to log attachment download activities directly in the work notes of the record.
+
+This tool is particularly useful in scenarios where data access needs to be monitored for compliance purposes or to ensure accountability in data handling.
+
+## Description
+
+The Attachments Download Logger Script Action is designed to automatically add work note of a record whenever an attachment is downloaded. This ensures that all attachment access activities are logged, providing a clear audit trail for administrators and compliance officers.
+
+## Functionality
+
+The Attachments Download Logger Script Action provides the following capabilities:
+- Automatically logs attachment download activities in the work notes of the associated record.
+- Captures details such as the user who downloaded the attachment and the timestamp and what attachment was downloaded.
+- Enhances visibility into data access activities for better compliance and accountability.
+- Operates seamlessly in the background without requiring manual intervention.
+
+## Usage Instructions
+
+
+### Creating the Script Action
+
+To create the Script Action for the Attachment Download Logger, follow these steps:
+
+1. Navigate to **System Policy > Events > Script Actions** in your ServiceNow instance.
+2. Click on the **New** button to create a new Script Action.
+3. Fill in the following fields:
+
+    - **Name**: `Add worknote for attachment download`
+    - **Event Name**: `attachment.read`
+    - **Active**: `true`
+    - **Order**: `100` (or any appropriate order value based on your instance configuration)
+    - **Script**:
+      ```javascript
+      //Add the attached script action code 
+     
+      ```
+
+4. Click **Submit** to save the Script Action.
+
+This Script Action will now automatically log attachment download activities in the work notes of the associated record.
+
+
+
+### Customizations 
+
+You can customize the script to include additional details, such as the IP address of the user or the reason for the download. Additionally, you can restrict the logging functionality to specific tables or user roles based on your requirements.
+
+If you want to restrict the logging functionality to a specific table, you can use the `current.table_name` property in your script. For example, to apply the logging only to the `incident` table, you can add the condition in the **condition Script** field as below.
+
+```javascript
+current.table_name == 'incident'
+```
+
+This ensures that the logging functionality is executed only for records in the `incident` table.
+
+
+## Category
+
+Server-Side Components / Script Actions / Attachment Downloads Logger
+
+## Screenshots
+<img width="1256" height="132" alt="2025-10-23_22-57-59" src="https://github.com/user-attachments/assets/dbd95461-2b81-40d8-9425-f3c98e724dd1" />