Self-Service & Knowledge Pack
Chaotic-1
⚙ Technical Requirements
ServiceNow scoped application / admin access
Relevant ServiceNow product/plugins for the selected pack capability
Validate in sub-production before promoting through update sets or application repository
Automation Readiness: High — The evidence shows a high volume of recurring, simple issues and incidents being used for requests, which are ideal candidates for self-service deflection.
Self-Service & Knowledge Pack — 5 rules
sn-ss-001
Password Reset Catalog Item & Automation
Catalog Item Priority: Critical Effort: Medium
To provide an immediate, automated solution for password reset requests, which are frequently logged as incidents, thereby reducing manual effort and improving user satisfaction.
Why this pack: This is a foundational self-service capability, converting a high-volume manual incident into a zero-touch automated request, which is the core purpose of this pack.
Trigger
User submits the 'Reset Password' catalog item from the Service Portal or Employee Center.
Conditions
·User is authenticated in the portal.
·User successfully completes any required identity verification steps (if configured).
Actions
·Trigger a Flow Designer flow to orchestrate the reset.
·Use an IntegrationHub spoke (e.g., Active Directory, Azure AD) to perform the password reset action.
·Send a confirmation email to the user with a temporary password or a link to set a new one.
·Close the request item automatically upon successful completion.
Evidence used
·Sample tasks INC0015281, INC0015717, INC0014995, and others show 'Password reset required' is a recurring incident summary.
·The high volume of interactions with users ('Work in Progress -> Pending User' at 43%) for incidents can be eliminated for simple requests like password resets.
ServiceNow implementation
Target table
·sc_req_item
Configuration area
·Flow Designer
Configuration trigger
·Service Catalog: When a catalog item is requested
Configuration conditions
·Item is 'Reset Password'
Implementation steps
·Create a new Catalog Item named 'Reset Password' with a simple description.
·Create a new Flow Designer flow triggered by this Catalog Item.
·Add the appropriate IntegrationHub action (e.g., 'Reset AD User Password'). Map the user from the 'Requested for' field.
·Add an 'If' condition to check if the reset action was successful.
·If successful, send a confirmation email using 'Send Email' action and update the Request Item state to 'Closed Complete'.
·If failed, create a Catalog Task assigned to the Service Desk for manual intervention and update the Request Item work notes.
·Activate the Flow.
Fields used
·requested_for
·state
·work_notes
Test cases
·Submit the catalog item as a test user. Verify the user's password is reset in the target system (e.g., Active Directory) and a confirmation email is received.
·Test the failure path by providing an invalid user or simulating a connection error to ensure a manual task is created.
Rollback notes
·Deactivate the Flow Designer flow.
·Deactivate the 'Reset Password' Catalog Item to hide it from the portal.
Requirements / prerequisites
·ServiceNow IntegrationHub subscription and relevant spoke (e.g., Microsoft AD Spoke).
·Credentials with permissions to reset passwords in the target identity system.
sn-ss-002
File Share Access Request Item
Catalog Item Priority: High Effort: Low
To convert 'File share access denied' incidents into a structured request, ensuring all required information is gathered upfront to reduce rework and streamline fulfillment.
Why this pack: This rule directly addresses the conversion of unstructured incidents into structured, self-service requests, a key strategy for improving service delivery and reducing manual clarification.
Trigger
User submits the 'Request File Share Access' catalog item.
Conditions
·All mandatory variables (e.g., Share Path, Justification) are populated.
Actions
·Create a Request, Request Item, and trigger a fulfillment flow.
·Create a catalog task for the fulfillment team to grant the access.
·Optionally, create an approval task for the manager of the requested share before creating the fulfillment task.
Evidence used
·Sample tasks INC0015736, INC0015884, and INC0016047 show 'File share access denied' is a common incident.
·The transition 'Work in Progress -> Pending User' occurs in 43% of tasks, indicating that initial submissions often lack necessary details which this catalog item will enforce.
·The close code 'Request created' (6.6%) suggests some access issues are already being identified as requests, confirming the need for a formal catalog item.
ServiceNow implementation
Target table
·sc_req_item
Configuration area
·Catalog Builder / Flow Designer
Configuration trigger
·Service Catalog: When a catalog item is requested
Configuration conditions
·Item is 'Request File Share Access'
Implementation steps
·Create a new Catalog Item named 'Request File Share Access'.
·Add mandatory variables: 'File Share Path or Name' (Single Line Text), 'Business Justification' (Multi-line Text).
·Create a Flow Designer flow for fulfillment.
·Step 1: Get Catalog Variables.
·Step 2: (Optional) Add 'Ask for Approval' action, setting the approver to a static group or dynamically from a CMDB record associated with the share.
·Step 3: If approved, use 'Create Catalog Task' action. Assign to the appropriate fulfillment group (e.g., 'Infrastructure Support'). Populate the task description with the variable values.
·Step 4: Update the Request Item stage and state based on task progress.
Fields used
·variables
·requested_for
·state
·stage
Test cases
·Submit a request for a file share. Verify the catalog task is created with the correct details and assigned to the right group.
·If approvals are configured, test both the approval and rejection paths.
Rollback notes
·Deactivate the 'Request File Share Access' Catalog Item.
Requirements / prerequisites
·Clearly defined fulfillment group for file share access.
·Defined approval process for access requests (if required).
sn-ss-003
Virtual Agent Topic for Common IT Issues
Virtual Agent Priority: High Effort: Medium
To deflect common, high-volume incidents by guiding users through troubleshooting steps and gathering structured information before a ticket is created.
Why this pack: This directly leverages a self-service channel (Virtual Agent) to provide guided assistance and deflection, which is a primary goal of improving the user's self-service experience.
Trigger
User initiates a conversation with Virtual Agent and selects a relevant topic (e.g., 'VPN Issues').
Conditions
·User input matches keywords associated with the topic.
Actions
·Ask clarifying questions to diagnose the issue (e.g., 'Are you on the corporate network?', 'What is the printer name?').
·Perform a knowledge base search based on user input and present top articles.
·If unresolved, offer to create an incident.
·Use the 'Create Incident' topic block, populating the description with the conversation summary.
Evidence used
·Recurring incident summaries like 'VPN connection drops intermittently', 'Unable to print to network printer', 'Application error on login', and 'Monitor display flickering' are ideal for conversational troubleshooting.
·'Virtual Agent' is already an established contact type for 11.9% of incidents, indicating user adoption of the channel.
·High rework ('Work in Progress -> Pending User' at 43%) suggests insufficient data collection, which a guided VA conversation can significantly improve.
ServiceNow implementation
Target table
·incident
Configuration area
·Virtual Agent Designer
Configuration trigger
·User selects a topic in the Virtual Agent client.
Configuration conditions
·N/A (triggered by user interaction)
Implementation steps
·Duplicate the 'Report an Issue' topic to create a new topic, e.g., 'Troubleshoot VPN'.
·Use 'Text' and 'Static Choice' controls to ask troubleshooting questions (e.g., 'Have you tried restarting your computer?').
·Use the 'Search KB' utility to find relevant knowledge articles based on keywords.
·Use a 'Card' control to display the KB article results.
·Ask the user if the issue is resolved. If not, use the 'Create Incident' topic block to create a ticket.
·Map conversation variables to the incident record's fields (e.g., short_description, description).
·Publish the topic and associate it with relevant keywords for NLU.
Fields used
·short_description
·description
·caller_id
Test cases
·Start a VA conversation and select the new topic. Follow the troubleshooting path and confirm a relevant KB is suggested.
·Follow the path to create an incident. Verify the incident is created with the conversation details in the description.
Rollback notes
·Deactivate the new Virtual Agent topic in the VA Designer.
Requirements / prerequisites
·ServiceNow Virtual Agent plugin (com.glide.cs.chatbot) is active.
·A small set of knowledge articles for common issues should exist to make deflection effective.
sn-ss-004
Knowledge Creation from Resolved Incidents Process
Knowledge Priority: Medium Effort: Low
To systematically capture solutions from resolved incidents into a searchable knowledge base, which fuels self-service deflection and provides consistent answers for service desk agents.
Why this pack: A robust knowledge base is the foundation of any successful self-service strategy. This rule establishes the process to build and maintain that foundation.
Trigger
An incident is moved to the 'Resolved' state.
Conditions
·The 'Create Knowledge' checkbox on the incident form is checked by the resolving agent.
Actions
·A business rule triggers the creation of a draft knowledge article.
·The incident's short description, description, and resolution notes are copied to the new KB article.
·The article is assigned to a knowledge management group for review and publishing.
Evidence used
·Close codes like 'Solved (Work Around)', 'Solved (Permanently)', and 'Training Issue' indicate that valuable resolution information exists within incidents but may not be formally captured.
·The high variety of recurring issues ('Monitor display flickering', 'Wifi disconnecting frequently', 'Software installation failing') shows a need for a centralized repository of solutions.
·The high rate of user follow-up ('Work in Progress -> Pending User' at 43%) could be reduced if users had access to KBs to solve issues or provide better initial information.
ServiceNow implementation
Target table
·incident
Configuration area
·Business Rule
Configuration trigger
·After an incident is updated.
Configuration conditions
·State changes to Resolved
·Knowledge checkbox is true
Implementation steps
·Ensure the 'Knowledge Management - KCS' plugin is active to provide the 'Knowledge' checkbox field on the incident form.
·Confirm the OOTB business rule 'Incident Create Knowledge' is active.
·Train service desk agents on the process: when resolving an incident with a reusable solution, check the 'Knowledge' box before setting the state to Resolved.
·Create a report or dashboard for Knowledge Managers to track articles in the 'Draft' state that need review and publication.
·Promote knowledge usage via search in the Service Portal and Virtual Agent.
Fields used
·knowledge
·state
·short_description
·close_notes
Test cases
·Resolve an incident and check the 'Knowledge' box. Verify that a new KB article is created in the 'Draft' state.
·Verify the content from the incident (short description, resolution notes) is correctly copied to the draft article.
Rollback notes
·Deactivate the 'Incident Create Knowledge' business rule.
·Alternatively, hide the 'Knowledge' checkbox from the incident form via a UI Policy or Form Layout configuration.
Requirements / prerequisites
·Knowledge Management module must be enabled and configured.
·A defined process and role (e.g., Knowledge Manager) for reviewing and publishing articles.
sn-ss-005
Identify and Convert 'Request-like' Incidents
Catalog Item Priority: Medium Effort: Medium
To analyze incidents that should have been requests and systematically convert them into catalog items, guiding users to the correct channel and enabling structured, repeatable fulfillment.
Why this pack: This rule focuses on improving the front-end of self-service by ensuring users are presented with the correct catalog of services, preventing process misuse and improving data quality from the start.
Trigger
Periodic review (e.g., monthly) of incidents with a specific close code.
Conditions
·Incident close_code is 'Request created'
Actions
·Run a report on the incident table, grouped by short description, for all tickets closed as 'Request created'.
·Identify the top 3-5 most frequent requests being logged as incidents.
·Create new catalog items for these services (e.g., 'Hardware Replacement', 'New Software Installation').
·Promote these new items on the Service Portal/Employee Center homepage.
Evidence used
·The close code 'Request created' is used for 6.6% of all incidents, providing a clear, data-driven list of candidates for new catalog items.
·Specific examples like INC0014380 ('Unable to print') and INC0014805 ('Laptop will not power on') were closed with 'Request created', indicating these are service requests, not incidents.
·Using the incident process for requests bypasses proper approvals and fulfillment workflows, leading to process deviations and rework.
ServiceNow implementation
Target table
·incident
Configuration area
·Reporting / Catalog Builder
Configuration trigger
·N/A (Process/Analysis Task)
Configuration conditions
·N/A
Implementation steps
·Navigate to Reports > Create New.
·Set Data source to the Incident [incident] table.
·Group by 'Short description'.
·Add a filter condition: 'Close code' is 'Request created'.
·Save and run the report. Schedule it to run monthly.
·Based on report findings, use Catalog Builder to create new catalog items for the top recurring requests.
·Develop a fulfillment flow for each new item in Flow Designer, including any necessary approvals and tasks.
·Feature the new items on the portal homepage to increase visibility.
Fields used
·close_code
·short_description
Test cases
·Verify the report accurately captures incidents with the 'Request created' close code.
·For each new catalog item created, test the end-to-end submission and fulfillment process.
Rollback notes
·New catalog items can be deactivated to remove them from the portal. The report can be deleted.
Requirements / prerequisites
·Access to the ServiceNow reporting module.
·A process owner responsible for analyzing the report and commissioning new catalog items.