Introduction

In the environment discussed in this article, recurring delays were caused by handover costs for extraction procedures and work bottlenecks stemming from permission differences. To address this, I created a PowerShell utility with a GUI that supports raw data export and Database View definition.

This post summarizes the background, implementation policy, and outcomes.

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. Each department needs a different format (CSV/JSON/Excel).
  2. Teams want the same column layout every time, but list-view changes often break consistency.
  3. If you need a standard export with all columns and internal names, documentation and handover costs rise sharply.
  4. In some cases, extra coordination is needed around CSV export permissions.

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 consists of three tabs.

1. Export tab

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

The goal is to standardize extraction procedures without blocking departmental data usage.

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

The goal is to close the operational gap in ServiceNow’s standard UI and reduce definition mistakes.

3. Settings tab

  • Instance name
  • Authentication method (user ID + password / API key)
  • Language setting

Inputs are stored in settings.json to reduce repetitive setup. Sensitive values are encrypted with Windows DPAPI (CurrentUser), so decryption is limited to the same user on the same device.

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 with plain text copy/paste in the worst case.

This trade-off minimized adoption barriers while preserving immediate practical value.

Effects after introduction

The biggest effects after introduction were the following three points.

  1. Inquiries to maintenance shifted from extraction procedures to data utilization consultation.
  2. Missing definitions and typos in Database View creation decreased.
  3. Formats became more consistent across departments, reducing preprocessing load for automated aggregation.

A particularly valuable outcome was that operations teams could do first-pass analysis in Excel while integration teams used JSON in parallel.

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.