diff --git a/Attachments/Delete Attachments - Approvals/readme.md b/Attachments/Delete Attachments - Approvals/readme.md
new file mode 100644
index 0000000000..070c3cb6b9
--- /dev/null
+++ b/Attachments/Delete Attachments - Approvals/readme.md	
@@ -0,0 +1,3 @@
+Many organizations still prefer copying over the attachments from RITM or any ticket type that has approval required to its corresponding approvals by using GlideSysAttachment.copy()
+Which ideally makes sense till the time approval is needed however, when approvals are actioned (approved/rejected) there is no need for attachments to stay on the approval record till eternity (it will be stored at its ticket level). 
+Use this script as a scheduled script to remove attachments from closed (approved/rejected) approval records and help consume less storage.
diff --git a/Attachments/Delete Attachments - Approvals/script.js b/Attachments/Delete Attachments - Approvals/script.js
new file mode 100644
index 0000000000..0519a52d09
--- /dev/null
+++ b/Attachments/Delete Attachments - Approvals/script.js	
@@ -0,0 +1,41 @@
+deleteinactiveattachments();
+
+//deletes from approval table
+function deleteinactiveattachments() {
+    var appr = new GlideRecord('sysapproval_approver');
+//	appr.addQuery('sys_id','2d7f326287351ad0195eb99c8bbb35b5'); //uncomment this and replace sys_id and use this to check for 1 record
+    appr.addEncodedQuery('state!=requested^ORstate=NULL');
+    appr.query();
+    while (appr.next()) {
+        var answer = deleteparentattachment(appr.sys_id);
+        deletechildattachment(appr.sys_id);
+        if (answer == true || answer == 'true') {
+            appr.comments = "Attachment's were removed from this record. If still needed it can be located at the corresponding ticket level.";
+            appr.autoSysFields(false);
+            appr.setWorkflow(false);
+            appr.update();
+        }
+    }
+}
+//deletes from sys_attachment table
+function deleteparentattachment(record) {
+    var attach_found = false;
+    var attach_primary = new GlideRecord('sys_attachment');
+    attach_primary.addQuery('table_sys_id', record);
+    attach_primary.query();
+    while (attach_primary.next()) {
+        attach_primary.deleteRecord();
+        attach_found = 'true';
+    }
+    return attach_found;
+}
+
+//deletes from sys_attachment_doc table
+function deletechildattachment(record) {
+    var attach_child = new GlideRecord('sys_attachment_doc');
+    attach_child.addQuery('sys_attachment.table_sys_id', record);
+    attach_child.query();
+    while (attach_child.next()) {
+        attach_child.deleteRecord();
+    }
+}
diff --git a/Background Scripts/Get Duplicate/readme.md b/Background Scripts/Get Duplicate/readme.md
new file mode 100644
index 0000000000..23de281b78
--- /dev/null
+++ b/Background Scripts/Get Duplicate/readme.md	
@@ -0,0 +1,3 @@
+Using GlideAggregate function to find out tickets (tasks) with same number. OOB there happens to be a Unique checkbox at dictionary level
+and if in case not set to True it might create duplicate numbered tickets.
+Script will help find, ticekts if any.
diff --git a/Background Scripts/Get Duplicate/script.js b/Background Scripts/Get Duplicate/script.js
new file mode 100644
index 0000000000..4ebdc39422
--- /dev/null
+++ b/Background Scripts/Get Duplicate/script.js	
@@ -0,0 +1,8 @@
+var dpchk = new GlideAggregate('task');               
+dpchk.groupBy('number');                             
+dpchk.addHaving('COUNT', '>', 1);
+dpchk.query();
+while(dpchk.next())	
+{
+		gs.print(dpchk.number);                               
+}
diff --git a/Background Scripts/Revert to previous working version of workflow /readme.md b/Background Scripts/Revert to previous working version of workflow /readme.md
new file mode 100644
index 0000000000..a535acc1b0
--- /dev/null
+++ b/Background Scripts/Revert to previous working version of workflow /readme.md	
@@ -0,0 +1,4 @@
+How often you come across cases where any version update to workflow breaks some other element of the existing workflow in PRD. Consider a case where more than one developer works on workflow and the updates are not in sync. When pushed to PRD breaks the workflow and as the issue is in PRD all you need to do is a break-fix at the soonest.
+The idea is to return to a stable, known version of the workflow to ensure continuity and productivity, while investigating or fixing the problems in the newer version and thus reverting to previous working version of workflow is the only resort.
+
+Use this as a background script/fix script and execute by merely changing the sys_id of workflows from 'wf_workflow_version' table.
diff --git a/Background Scripts/Revert to previous working version of workflow /script.js b/Background Scripts/Revert to previous working version of workflow /script.js
new file mode 100644
index 0000000000..7879dcfd55
--- /dev/null
+++ b/Background Scripts/Revert to previous working version of workflow /script.js	
@@ -0,0 +1,15 @@
+var updatevftoprevious = new GlideRecord('wf_workflow_version');
+
+if (updatevftoprevious.get('4f215adf1b533d54bc97dce0b24bcb31')) //pass sys_id of current workflow version here
+{
+    updatevftoprevious.published = false; //sets the published status to false
+    updatevftoprevious.update();
+}
+
+
+var updatevftopreviousvf2 = new GlideRecord('wf_workflow_version');
+if (updatevftopreviousvf2.get('2cb9a6418713b5140b0f0d490cbb3512')) //pass sys_id of workflow version that needs to be reverted to
+{
+    updatevftopreviousvf2.published = true;//sets the published status to false
+    updatevftopreviousvf2.update();
+}
diff --git a/Background Scripts/Revert to previous working version of workflow/readme.md b/Background Scripts/Revert to previous working version of workflow/readme.md
new file mode 100644
index 0000000000..a535acc1b0
--- /dev/null
+++ b/Background Scripts/Revert to previous working version of workflow/readme.md	
@@ -0,0 +1,4 @@
+How often you come across cases where any version update to workflow breaks some other element of the existing workflow in PRD. Consider a case where more than one developer works on workflow and the updates are not in sync. When pushed to PRD breaks the workflow and as the issue is in PRD all you need to do is a break-fix at the soonest.
+The idea is to return to a stable, known version of the workflow to ensure continuity and productivity, while investigating or fixing the problems in the newer version and thus reverting to previous working version of workflow is the only resort.
+
+Use this as a background script/fix script and execute by merely changing the sys_id of workflows from 'wf_workflow_version' table.
diff --git a/Background Scripts/Revert to previous working version of workflow/script.js b/Background Scripts/Revert to previous working version of workflow/script.js
new file mode 100644
index 0000000000..7879dcfd55
--- /dev/null
+++ b/Background Scripts/Revert to previous working version of workflow/script.js	
@@ -0,0 +1,15 @@
+var updatevftoprevious = new GlideRecord('wf_workflow_version');
+
+if (updatevftoprevious.get('4f215adf1b533d54bc97dce0b24bcb31')) //pass sys_id of current workflow version here
+{
+    updatevftoprevious.published = false; //sets the published status to false
+    updatevftoprevious.update();
+}
+
+
+var updatevftopreviousvf2 = new GlideRecord('wf_workflow_version');
+if (updatevftopreviousvf2.get('2cb9a6418713b5140b0f0d490cbb3512')) //pass sys_id of workflow version that needs to be reverted to
+{
+    updatevftopreviousvf2.published = true;//sets the published status to false
+    updatevftopreviousvf2.update();
+}