Self-Service & Knowledge Pack
Bugs - Status
⚙ 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: Medium — The evidence shows clear deflection opportunities with bugs closed early in the lifecycle, but the organization's low automation appetite suggests a phased approach starting with foundational knowledge and catalog items.
Self-Service & Knowledge Pack — 4 rules
sn-ss-001
Bug Submission Record Producer with Deflection
Catalog Item Priority: Critical Effort: Medium
Standardize the bug submission process to improve initial data quality and proactively deflect common issues or invalid bugs before they are created, reducing overhead for the triage team.
Why this pack: This rule establishes the primary self-service entry point for users, using a catalog item (Record Producer) and contextual search to guide users and enable deflection, which is a core function of this pack.
Trigger
User navigates to the Service Catalog/Employee Center to report a bug.
Conditions
·User needs to submit a new bug report.
Actions
·User is presented with a structured form (Record Producer) to capture bug details.
·As the user types in the description, relevant Knowledge Base articles are automatically displayed.
·Upon submission, a bug record is created with standardized, high-quality information.
Evidence used
·High volume of bugs closed without development work: Variant 'Triage -> Closed' (4.54% of tasks) and 'New -> Closed' (3.36% of tasks).
·Multiple, inconsistent starting points for work: 'Start -> Open' (38.52%), 'Start -> New' (36.39%), 'Start -> Triage' (14.56%).
·Rework loop 'New -> New' (6.19% of tasks) suggests that bugs lack sufficient information at creation and require updates before triage can proceed.
ServiceNow implementation
Target table
·task
Configuration area
·Record Producer
Configuration trigger
·User submission from Service Catalog or Employee Center.
Configuration conditions
·N/A (triggered by user action)
Implementation steps
·Create a new Record Producer named 'Report a Bug'.
·Set the 'Table name' to the table where bugs are currently managed (e.g., a custom table, 'pm_bug', or 'incident').
·Add variables to the form: 'Project' (Reference to Project table or Choice list), 'Application Version' (String), 'Steps to Reproduce' (Multi-line text), 'Expected Result' (Multi-line text), 'Actual Result' (Multi-line text), 'Attachments' (Attachment).
·Configure the Record Producer's 'Display settings' to enable 'Show help' and provide instructions.
·Enable 'Contextual Search' in the 'Behavior' section. Target the relevant Knowledge Base and map search to the 'Short description' or 'Actual Result' variable.
·Publish the Record Producer to the appropriate Service Catalog and make it visible on the Employee Center/Service Portal.
Fields used
·short_description
·description
·project
·priority
Test cases
·Verify that submitting the form creates a bug record in the correct table with all variables mapped correctly.
·Test that typing keywords related to known issues in the short description variable displays relevant knowledge articles.
·Confirm the Record Producer is accessible to end-users on the portal.
Rollback notes
·Deactivate the Record Producer to hide it from the catalog. Existing submission methods will remain unaffected.
Requirements / prerequisites
·Service Catalog plugin (active by default).
·A defined Knowledge Base to power contextual search for deflection.
sn-ss-002
Create Knowledge Articles for 'Closed at Triage' Bugs
Knowledge Priority: High Effort: Medium
To create a repository of knowledge articles based on the most common reasons bugs are closed without development, directly fueling the deflection capabilities of the Bug Submission Record Producer.
Why this pack: This rule directly supports self-service by generating the knowledge content required for users to solve their own issues or understand why their submission is not a valid bug, reducing ticket volume.
Trigger
Analysis of historically closed bugs.
Conditions
·Bug record has a variant of 'Triage -> Closed' or 'New -> Closed'.
Actions
·Analyze the close notes and comments for these bugs to find common themes.
·Create user-facing Knowledge Articles for each theme (e.g., 'How to configure X feature', 'Common error message Y and its solution').
·Tag articles with relevant project names and keywords.
Evidence used
·Significant volume of tasks closed immediately after intake: 'Triage -> Closed' is the 4th most common variant (4.54% of tasks).
·Transition 'New -> Closed' accounts for another 4.54% of all transitions.
·These rapid closures indicate a high potential for user self-service if the reasons for closure (e.g., configuration error, known issue, feature request) are documented.
ServiceNow implementation
Target table
·kb_knowledge
Configuration area
·Knowledge Management
Configuration trigger
·Manual analysis, followed by content creation.
Configuration conditions
·N/A (process-driven task)
Implementation steps
·Create a report of all bugs from the last 90 days that were closed in the 'New' or 'Triage' state.
·Export the list including 'Close notes', 'Comments', and 'Project'.
·Manually review and categorize the reasons for closure (e.g., Duplicate, User Error, Works as Designed, Enhancement Request).
·For common 'User Error' or 'Works as Designed' categories, create new Knowledge Articles in a designated Knowledge Base.
·Write articles from the user's perspective, focusing on the problem and the solution/explanation.
·Use the 'Meta' field on the Knowledge Article form to add relevant keywords from the original bug reports to improve search results.
·Establish a process to periodically review new 'Triage -> Closed' bugs for more knowledge opportunities.
Fields used
·state
·close_notes
·comments
·project
Test cases
·Search for a known closed-at-triage issue in the Service Portal and verify the new Knowledge Article appears.
·Verify the new articles are displayed by the contextual search on the Record Producer (from rule sn-ss-001).
Rollback notes
·Retire or delete the created knowledge articles if they are found to be inaccurate or unhelpful.
Requirements / prerequisites
·Knowledge Management plugins (active by default).
·Permissions for development leads or a knowledge manager to create and publish articles.
sn-ss-003
Automate Knowledge Creation from Resolved Bugs
Flow Designer Priority: Medium Effort: Medium
To create a repeatable process for capturing valuable resolution information from successful bug fixes, building a 'Known Error' database that can prevent duplicate bug reports and assist developers.
Why this pack: This rule uses automation to generate the knowledge content that fuels self-service and deflection, ensuring the knowledge base grows organically with the resolution of work.
Trigger
Bug record state changes to 'Resolved'.
Conditions
·Bug state changes to 'Resolved'.
·The bug resolution notes are not empty.
Actions
·Automatically create a Knowledge Article Submission record.
·Pre-populate the submission with the bug's number, description, and resolution details.
·Assign the submission to the bug's assignee or a knowledge manager for review and publication.
Evidence used
·High volume of bugs are successfully resolved: 'Pull Request Sent -> Resolved' (38.42% of tasks) is the second most frequent transition.
·Each resolved bug is a potential source of knowledge for workarounds or complex solutions that could be reused or help deflect future similar reports.
ServiceNow implementation
Target table
·kb_submission
Configuration area
·Flow Designer
Configuration trigger
·Record Updated on the Bug table.
Configuration conditions
·State changes to Resolved
·Resolution notes is not empty
Implementation steps
·Create a new Flow in Flow Designer triggered when a bug record is updated.
·Add a condition: 'State' changes to 'Resolved'.
·Add an action: 'Create Record' on the 'Knowledge Submission' [kb_submission] table.
·Map fields from the bug record to the submission: Set 'Short description' to the bug's 'Short description', set 'Article body' to a combination of bug 'Description' and 'Resolution notes'.
·Set the 'Knowledge Base' to a pre-defined 'Known Errors' or technical KB.
·Assign the submission to the 'Resolved by' user from the bug record for authoring.
·Activate the Flow.
Fields used
·state
·short_description
·description
·close_notes
·resolved_by
Test cases
·Resolve a test bug with detailed resolution notes.
·Verify that a new Knowledge Submission record is created and assigned to the correct user.
·Verify the submission record contains the correct information from the source bug.
Rollback notes
·Deactivate the Flow in Flow Designer to stop the automatic creation of knowledge submissions.
Requirements / prerequisites
·Flow Designer plugin (active by default).
·Knowledge Management Advanced plugin to use the `kb_submission` table and workflow.
sn-ss-004
Virtual Agent Topic for Bug Status Check
Virtual Agent Priority: Medium Effort: Low
To provide bug submitters with an instant, automated channel to check the status of their reported bugs, reducing the need for them to contact developers or managers for updates and improving their experience.
Why this pack: This rule implements a key self-service channel (Virtual Agent) for a common, high-frequency, low-complexity interaction (status checks), which is an ideal starting point for an organization with a low automation appetite.
Trigger
User initiates the 'Check Bug Status' topic in the Virtual Agent chat client.
Conditions
·User has submitted a bug and wants to know its current status.
Actions
·VA prompts the user for the bug number.
·VA looks up the record.
·VA displays the current State, Assignee, and latest update (comment/work note).
·VA provides a link to the record on the portal.
Evidence used
·The bug resolution process is very long and complex, with an average duration of over 2700 hours and many different states ('Coding In Progress', 'Ready for QA', 'In Review', 'In Validation').
·The long duration implies that submitters will frequently seek status updates. Providing a self-service channel for this is a classic, high-value VA use case.
ServiceNow implementation
Target table
·sys_cs_topic
Configuration area
·Virtual Agent
Configuration trigger
·User selects topic or types keywords like 'bug status', 'check on my bug'.
Configuration conditions
·N/A (user-driven)
Implementation steps
·In Virtual Agent Designer, create a new Topic named 'Check Bug Status'.
·Add keywords for NLU discovery: 'bug status', 'check ticket', 'update on my bug'.
·Add a 'Text' input node to ask the user for the Bug Number.
·Add a 'Look Up Record' utility to search the bug table using the number provided by the user.
·Add a condition to check if a record was found.
·If found, use a 'Bot Response' (Card or Text) to display key fields from the record: 'Number', 'State', 'Assigned to', 'Short description'. Provide a scripted link to the record on the Service Portal.
·If not found, use a 'Bot Response' to inform the user the record could not be found.
·Publish the topic.
Fields used
·number
·state
·assigned_to
·short_description
Test cases
·Start a VA conversation and trigger the topic with a keyword.
·Provide a valid bug number and verify the correct status is returned.
·Provide an invalid number and verify the 'not found' message is displayed.
·Click the link provided by the VA and verify it opens the correct record.
Rollback notes
·Deactivate the Topic in the Virtual Agent Designer console. The VA will no longer present it as an option.
Requirements / prerequisites
·Virtual Agent Lite or Pro plugin enabled.
·A Service Portal or Employee Center where the VA chat client is deployed.