Introduction

As ServiceNow operations and maintenance continue, the way Database Views are created tends to become person-dependent because it relies on foundational RDB knowledge. In addition, even when trying to utilize data through the GUI, large data volumes can exceed export limits and make export itself impossible, selected columns can change depending on list-view state, and attachments are scattered across individual records and are costly to collect. To address this, I built a PowerShell utility with a GUI that supports raw data export and Database View definition.

This article organizes the background, implementation policy, design, and operational impact based on the implementation in the public repository.

Background 1: Data export is possible, but operations are heavy

ServiceNow’s standard UI can export data. In real operations, however, the following issues accumulate.

  1. Teams want the same column layout every time, but list-view changes often affect output.
  2. If a fixed export with all columns and internal names is required, documentation and handover costs rise sharply.
  3. With large datasets, GUI export itself becomes heavy, and managing execution and re-execution becomes difficult.

As a result, maintenance teams spend time supporting how to extract data rather than how to use data. I changed the approach and prepared a structure where each department can run standardized exports on its own through APIs.

Background 2: Database View creation easily exposes RDB knowledge gaps

Database View is useful, but it is a high hurdle for non-engineers or users with limited RDB experience.

  • sys_db_view and sys_db_view_table are handled in separate contexts, requiring many screen transitions.
  • It is hard to review internal column names in one place.
  • In environments without admin rights, users may need to inspect internal names elsewhere and bring them back manually.
  • Handwritten WHERE/JOIN definitions are prone to typos and reference mistakes.

For these reasons, I concluded that users needed GUI support that lets them assemble definitions while viewing candidates.

What I built: PS1 SNOW Utilities

PS1 SNOW Utilities is a PowerShell tool that consolidates frequent ServiceNow operational tasks into one GUI. The primary tab structure is as follows.

1. Export tab

  • Select target table (or enter manually)
  • Set filter (all records / sys_updated_on period)
  • Select output format (CSV / JSON / Excel)
  • Split CSV export for large record counts
  • Choose output folder and review execution logs

The operational goal is to standardize extraction procedures and reduce differences between operators.

2. Database View Editor tab

  • Input view internal name and label
  • Set base table and prefix
  • Add JOINs (left/right columns, variable prefix, LEFT JOIN option)
  • Refresh column candidates and select displayed columns
  • Create view and show result link

By assembling definitions while viewing candidates, this reduces the burden of manually entering WHERE and JOIN conditions while moving back and forth across ServiceNow screens.

3. Attachment Harvester tab

  • Collect related attachments in bulk by update period
  • Avoid filename collisions by adding sequence numbers
  • Record retrieval process logs

This helps execute audit and investigation attachment collection through reproducible procedures.

4. Truncate tab

  • Full table deletion for development use
  • Confirmation code input, target information display, and retry settings

Because this is a dangerous operation, production use is not recommended. It is intended for data reload testing in verification environments.

5. Settings tab

  • Instance name
  • Authentication method (user ID + password / API key)
  • Language setting (Japanese/English)
  • Theme setting (Dark / Light)
  • Custom domain connection setting (instanceDomain)

Inputs are stored in settings.json, and sensitive values are encrypted and stored with Windows DPAPI (CurrentUser).

Key design points

What I prioritized in this implementation was design that reduces maintenance burden during operations.

  1. Centralizing communication processing in shared functions
    Built around Invoke-SnowRequest, wrapping GET/POST/PATCH/DELETE/attachment retrieval so authentication, exception handling, and logging are not scattered.

  2. Separating UI construction from display control
    UI elements are built with Build-*, while display switching is handled with Apply-*Language and Set-Theme.

  3. Stabilizing settings persistence
    Through Load-Settings / Save-Settings and Request-SaveSettings, the design suppresses both missed saves and excessive saves.

  4. Multiple confirmations for dangerous operations
    Truncate processing includes confirmation codes and target display to lower misoperation risk.

  5. Implementation designed for log traceability
    Through the Logs tab and ConvertTo-LogCompactJson, execution results can be tracked later.

Practical trade-offs in implementation

In corporate environments, distributing installers or introducing resident applications can be difficult. So I prioritized a PowerShell script delivery model that can run even as plain text.

This trade-off minimized adoption barriers while shortening time to initial use on site.

Effects after introduction

The following four effects were confirmed after introduction.

  1. Export procedures became fixed on screen, reducing explanation load for each extraction request.
  2. Manual WHERE-clause entry on ServiceNow UI during Database View creation was reduced.
  3. Attachment collection can be executed in bulk with period conditions, shortening repetitive investigation work.
  4. Saved settings reduced repeated input of instance names and credentials.

The impact is not flashy, but there is practical value in steadily compressing repeated work time for operations staff.

Constraints and caveats

  • Table lists rely on sys_db_object; depending on ACL settings, retrieval may fail (manual input is a workaround).
  • In some environments, there are constraints on automatically saving WHERE/JOIN definitions, requiring manual completion in ServiceNow.
  • This tool is independent from ServiceNow, Inc. and receives no endorsement, warranty, or support from the company.

Conclusion

PS1 SNOW Utilities was created to reduce practical bottlenecks in data extraction and Database View definition.

Personally, I had known that PowerShell can build GUIs, but I had never thought of driving the effort myself. With support from generative AI, I was able to shape this utility with near no-code, instruction-based development. That experience strongly reinforced how fast AI is evolving. At the same time, I believe conventional low-code/no-code tools are entering a phase where they must redefine their advantage and face unavoidable commoditization pressure.