Before Reporting a Bug
Complete the basic troubleshooting checks, record the results, then open an SN Utils support ticket with a reproducible example.
Last updated: September 9, 2026
Your environment details
Collected from this browser profile. Review or correct the details before sharing. No instance data, credentials, or license keys are collected.
A store listing identifies the build, not how it was installed. Confirm the installation source. If a value is unavailable, enter it manually. Firefox, Safari, and older extension builds may not allow detection on this page.
Detecting browser and extension details...
Before opening a bug report, complete the checks below and include your results. A report such as "it stopped working" does not give us enough information to reproduce or investigate the problem. You do not need to diagnose the code, but you do need to show what fails, where it fails, and what you have tested.
If a check is unavailable because of access or company policy, write Not tested and explain why. Do not bypass company controls to complete a test. For billing, account access, or feature requests, go directly to support; this checklist is for extension bugs. If you cannot sign in to open a ticket, email support@snutils.com.
The Your environment details panel above detects what this browser can share and shows an editable preview. Use Copy details or Use these details in a ticket. The ticket form includes the preview with your message when you submit; you can edit it or uncheck Include environment details. Detection runs in the browser, and details are only sent when you submit a ticket. The handoff stays in this tab for up to 30 minutes.
Automatic extension detection on this docs page requires SN Utils 10.2.3.0 or newer in Chrome or Edge. With an older build, try Detect again on the ticket page. If detection is unavailable, enter the missing values manually.
1. Check the docs, version, and setup
- Search the Extension Guide, common issues, and changelog for the affected feature.
- Use the environment preview above to collect your details, then confirm any missing or approximate values. Record your exact SN Utils version, browser version, operating system, and extension variant: regular, OnPrem, or Debug. Include the installation source, such as Edge Add-ons or the Chrome Web Store. "Latest version" is not enough to compare reports.
- Check for an available extension update, then reload the affected ServiceNow tabs. Tabs that were already open can still contain the previous extension code. If the issue remains, restart the browser and retry.
- Check that SN Utils is enabled and has permission to run on the affected site. For custom or proxy domains, see installation and domain support.
- Make sure only one SN Utils variant is enabled on the page. Running regular, OnPrem, or Debug together can cause conflicts. See running both versions at once.
Do not reset settings or uninstall as a first step. If you later need to do either, export your settings first so you can restore your setup.
2. Reproduce the smallest example
Write the exact steps from opening the page to the failed action. Include the table, feature, input, expected result, and actual result. Specify whether you are in a classic list, related list, Workspace, or another ServiceNow interface.
- Try a standard table and a simple, non-sensitive input before testing your full scenario.
- Repeat the action and record whether it fails every time or intermittently, for example "3 out of 5 attempts."
- Note when it last worked and any known browser, extension, ServiceNow, or configuration changes since then. Do not guess an earlier version.
- Where there is an equivalent native ServiceNow action, test that too. For example, apply the same condition with the normal list filter builder. If needed, disable SN Utils temporarily, reload, and test the native action again; then re-enable it and reload.
3. Compare browsers and isolate extensions
Test the same steps on the same instance in another supported browser, such as Chrome and Edge. Confirm SN Utils is installed, enabled, and allowed on the site in each browser. Record both browser and extension versions, since store releases may differ.
Then test in a fresh browser profile with only SN Utils enabled, if your organization allows it. Start with default settings before importing your usual configuration. Alternatively, temporarily disable other optional extensions that modify ServiceNow pages and reload. Restore them after testing. Leave required security extensions enabled and mention that limitation in the report.
For a Pro feature, confirm your existing Pro license or trial is active in the comparison browser or profile. See connecting the extension. If activation is unavailable, record the test as Not tested with the reason; an inactive license is not a reproduction of the bug.
A private or incognito window is only a useful SN Utils test if the extension is explicitly allowed there and you have confirmed it is active.
4. Compare instances and access routes
Repeat the same small example on another instance, ideally a PDI or an unrelated test instance. Record the ServiceNow release and patch if known, your relevant roles, and whether the example uses a standard or customized page. Never share credentials.
Testing DEV and TEST behind the same corporate proxy is useful, but both still share that access path. State whether each test uses a normal service-now.com domain, a custom domain, or a proxy such as Microsoft Defender for Cloud Apps (service-now.com.mcas.ms). If your organization already provides an approved direct access route, compare it; otherwise mark that test unavailable.
Use a result table instead of "tested elsewhere":
| Browser and SN Utils versions | Instance / release | Access route | Profile / extensions | Result |
|---|---|---|---|---|
| Fill in exact versions | DEV / release and patch | Corporate proxy | Usual profile | Fails: describe what happens |
| Fill in exact versions | Same DEV instance | Same route | Second browser | Works / fails / not tested, with reason |
| Fill in exact versions | PDI / release and patch | Standard domain | Only SN Utils | Works / fails / not tested, with reason |
Use anonymized instance labels when needed. Change one variable at a time where possible. A result that differs between browsers or instances helps narrow the investigation; it does not by itself prove the cause.
5. Capture console errors while reproducing
Open developer tools on the affected ServiceNow tab before reproducing the issue. In Chrome or Edge, open the Console with Ctrl+Shift+J on Windows/Linux or Cmd+Option+J on macOS.
- Clear any text filters, enable warnings and errors, and turn off Selected context only if enabled so messages from embedded frames are included.
- Clear old messages, then enable Preserve log in Console settings so a reload does not erase the evidence.
- Reload the page and repeat the exact failing action.
- Copy relevant errors and expanded stack traces as text. Include the time of the action and any visible message in the SN Utils dialog. A screenshot or short recording can show what happened alongside the console output.
- If nothing appears, report No console errors while reproducing with warnings/errors visible and filters cleared. A quiet console does not mean the feature worked.
For request failures, also open the Network tab before reproducing. Record the failed request's status and a sanitized URL if one appears. Do not attach a full network export unless support requests it and you have reviewed it for sensitive data.
Browser references: Microsoft Edge Console and Microsoft Edge Network.
Example: Apply query does nothing
For the list query editor, include these details in addition to the checks above:
- Open a standard list such as Incidents and wait until it finishes loading.
- Open Edit list query, enter a simple valid query such as
active=true, and click Apply query. Compare with the same condition in the native filter builder. - Try Ctrl+Enter or Cmd+Enter separately. State whether the dialog closes, whether the breadcrumb changes, and whether the list refreshes. Note any warning beside the buttons.
- Check whether Cancel and Esc close the dialog.
- Include the browser/instance comparison above, especially whether affected instances share a proxy or custom domain.
6. Open a support ticket with your results
Once you have completed the checks, open a support ticket and paste the template below into the description. Sign in if prompted. If you cannot sign in, email support@snutils.com with the same information. Replace every placeholder with a result or Not tested: reason. Include the relevant details in the ticket itself, even if you already discussed the issue in Slack.
Remove passwords, tokens, cookies, license keys, personal information, and confidential record data from text, screenshots, and recordings before attaching them.
Feature and short problem summary: SN Utils version / variant / installation source: Browser version / operating system: ServiceNow release and patch / relevant roles: Page type / table / standard or customized: Domain type / proxy or custom access route: Last known working date or version / recent changes: Steps to reproduce, including a sanitized example input: 1. 2. 3. Expected result: Actual result / frequency: Docs and changelog checked: Update, tab reload, and browser restart result: Site permissions and duplicate SN Utils variants checked: Native ServiceNow action result: Second browser result (include both versions): Fresh profile / other extension isolation result: Second instance or PDI result (include access route): Console errors and stack trace, or explicit no-error result: Failed network request/status, if relevant: Checks not possible and why: Sanitized screenshot or short recording:
Keep follow-up results in the same ticket so the reproduction steps and investigation stay together.