Platform Recon 101: Learning About an Unfamiliar ServiceNow Instance Through Data Archaeology

[andersonk17474]

Authors note - AI was used to generate significant portions of this document.

It's Monday, and I'm fresh into a new ServiceNow developer role at a company that I have just joined. I'm given access to the development environment, handed a few assignments to keep me occupied through the first week, and encouraged to start digging in. So where do I start? Beyond the scope of my first assignments for week one, how do I quickly figure out what is what in a platform that is completely unfamiliar to me?

Before we dive into process, a quick callout on analysis process using AI as the main engine of analysis and pattern discovery. The data volumes involved in a mature ServiceNow implementation frequently exceed what can be reviewed manually in a reasonable timeframe. As such, the use of AI enables rapid clustering, pattern identification, summarization, and hypothesis generation across datasets that would otherwise require days or weeks of analysis. While some level of hallucination should be expected, grounding the analysis in detailed source data and preserving the supporting extracts helps minimize inaccuracies while still providing a reasonable approximation of the platform's structure, operational patterns, and areas of investment.

I started with the update sets. I want to know first what the big development efforts were recently.  I have access to Microsoft Copilot, which I will use to decompose big data exports quickly. My first step is a list of every update set committed over the last two years. I export the data to CSV and load it into Copilot for analysis.  Before dropping in the file into the chat window, I spend a few minutes providing some context to the AI about my background and what I'm trying to learn. Ten years of ServiceNow experience, primarily in Service Catalog and workflow automation, along with an earlier career building PHP and SQL web applications. Then I ask a simple question: what patterns do you see in this development history?

 I meticulously record all the responses in text files, making a robust record of the input data and the AI findings, that later I can quickly compile into a document to help me and the AI understand the platform configuration from a high level. I save the source extracts, the prompts, the findings, the follow-up questions, and the resulting summaries all go into text files. The goal isn't just to get an answer. The goal is to build a growing body of notes that both I and the AI can use later as we begin piecing together a high-level understanding of the platform, the team, and the major initiatives that shaped the environment over time. I follow this same data decomposition process for a series of tables across the platform to help me build a well-rounded view of the platform.

For the update set analysis I pulled from two locations:

1. sys_update_set – pull the update set names, updated date, and updated by fields for a 2 year lookback to help me understand major efforts
2. sys_update_xml – this gives me a more granular view of the recent efforts, and for this I pull type, target name, update set, updated, and updated by fields on a 6 month lookback window

I take both data sets and feed them to Microsoft CoPilot chat, one at a time, asking for major patterns observed in the data.  From the AI pattern analysis, I then request the AI to produce an executive-level summary document from each data set and analysis summary that can be combined together to give a solid view of the major initiatives over the last two years, a more detailed view of the most recent efforts in the last 6 months, and a breakdown of which team members have expertise in their respective areas of the ServiceNow platform.

After getting a good view of the recent developments, and documenting the AI generated summary, I move on to the Service Catalog.  I am working in the DEV platform, so after I identify the most recent clone date from Prod, I ensure all my data pulls cutoff on the date of the last clone to ensure local testing data doesn’t skew my results. I pull several extracts to drive this analysis:

1. sc_req_item – timeboxed from the last clone date back 6 months.  I get two versions of this data, the raw export of all the requests, and a group-by export on the catalog item name field to provide request volume by catalog item.
2. sc_task – also timeboxed from the clone date back six months.  I also pull two versions of the data, the raw export of all records, and an additional export where the records are grouped by the assignment group. This provides insight into the fulfillment work being done for each request and what teams support which processes.

Each export is submitted to Microsoft Copilot for pattern analysis. The resulting findings, along with the original source data, are then combined in a second pass to generate an executive-level summary document highlighting major trends, high-volume request categories, fulfillment patterns, and areas that warrant further investigation.

The summary document should be viewed as a starting point rather than the final answer. After reviewing the findings, additional targeted analysis is often required. For example, some catalog items may appear with unusually high request volumes and warrant deeper inspection. In those cases, I typically perform additional exports focused on the individual catalog item, including request variables and fulfillment records, and then repeat the analysis process using the narrower dataset.

Not all platform data is easily accessible through standard list exports. Catalog variables, workflow activity, and related transactional data frequently require a scripted approach. For deeper investigations, I often use AI to help generate ServiceNow background scripts that query source tables, perform aggregations or data transformations, and output results in a CSV-like format suitable for further analysis. The resulting extracts can then be fed back into the overall analysis process to provide additional context and insight.

In practice, the most valuable discoveries often come from these targeted follow-up investigations rather than the initial large-scale exports. The first-pass analysis identifies where to dig. The second-pass scripted data extracts and subsequent analysis typically explains why those areas matter.

After working through the Service Catalog side of the house and getting a good understanding of what the user community is requesting on the target instance, it was time to pivot to what is being reported broken or failing.  The next stage of the analysis focused on the incident data.  For the incident analysis, due to data volume the date range was timeboxed much tighter than what was pulled from update sets or catalog space.  The initial export from the incident table was 60 days.  This may not be enough of a look back for some organizations, but the target instance I was investigating sent back almost 15k rows just from the 2-month lookback.  That felt sufficient for initial discovery of incident patterns.  A deeper lookback can certainly be performed or a deeper dive using a scripted approach can be performed as well, but for the initial discovery, 60 days provided significant data and sufficient pattern coverage to identify the major operational themes present within the incident population. Two main exports were performed, the first being the raw export that includes assignment group, short description, and the description field.  This was done in a scripted manner so that the description field could be truncated to a manageable length. The second export was a group-by on the assignment group field to provide a rollup of the volume the various support groups in the org are experiencing.  Both data sets were submitted to MS Copilot for pattern analysis, and the results were recorded in a temp file. After the first pass analysis, all the assets related to the incident data analysis (raw extracts and first pass analysis results) are submitted again the AI chatbot to generate the executive-level summary with the expanded detail section that calls out more granular details and major trends observed in the data.  

After understanding what had been built through update sets, what users were requesting through the Service Catalog, and what was breaking through incident analysis, the next question became: who supports all of it? To answer that question, I turned to assignment groups.

Assignment groups are one of the most valuable organizational artifacts in ServiceNow. Requests, tasks, incidents, approvals, notifications, and operational ownership frequently converge around assignment groups, making them an effective way to map support responsibilities.

The first extract grouped catalog tasks by assignment group to identify which teams were carrying the largest fulfillment workloads. A second pass grouped those tasks by catalog item and task description to better understand the specific processes each team supported. Some of this was duplicative in nature from the previous Service Catalog analysis.

Incident data was then analyzed in a similar fashion. Initial grouping by assignment group identified major support organizations. Additional analysis using categories, subcategories, and representative incident samples helped establish the operational themes associated with each team.  This export was also somewhat duplicative in nature to the incident analysis, but the goal in the analysis prompting was to focus solely on the assignment groups vs the larger incident patterns.

As with the previous datasets, the exports were analyzed using Copilot, with the source data and findings combined into a second-pass executive-level summary. The goal was not simply to measure workload, but to answer several important questions:

• Which teams support the platform's major business processes?
• Which groups specialize in automation, infrastructure, identity, HR, analytics, or application support?
• Where does operational demand concentrate?
• Who are the likely subject matter experts for specific platform capabilities?

By this stage of the analysis, I was really starting to get a good feel for what the org is doing on a daily basis and how this ServiceNow instance supported those business drivers.

After building an understanding of the Service Catalog, Incidents, work queues, and recent development efforts, I wanted to understand the team I had just joined. The question I had at this point was: who are this team's customers, and what are they asking for?

To answer that question, I shifted focus from the platform to the team's own queues. Using both incident and catalog task data, I extracted six months of work assigned to the team's support group, timeboxed to the most recent production clone date. The goal was to analyze the operational demand placed specifically on this one team.

The raw exports were submitted to Copilot for pattern analysis. The resulting AI-driven pattern analysis of the raw data helped identify the major business areas consuming team capacity, the types of requests being submitted, and the recurring operational responsibilities visible through the queue history.

This analysis allowed me to gain insight into what areas of the org depended heavily on ServiceNow and major patterns around the work being requested from a business perspective. The queue data revealed primary stakeholders, enhancements they requested, issues they encountered, and which teams generated the most workload. I was beginning to understand the people, processes, and business functions that the platform existed to support. The raw data and first pass analysis findings were then combined together and submitted to Copilot AI chat to generate the executive-level summary and the detail accounting of the major trends in the team work queues.

Next on the list was the CMDB. At this stage I understood the people, the work, and the operational patterns. Now I wanted to understand the technology itself. What systems exist? Which applications appear most important? Where are the major dependencies? Which platforms form the backbone of the environment? I started with extracts and AI-driven analysis of tables  cmdb_ci_appl and its larger parent table, cmdb_ci.

Unlike the previous datasets, the CMDB required a far more iterative approach. Raw exports tended to be noisy, excessively detailed, and often contained more information than was useful for a first-pass analysis.  I worked with MS Copilot to repeatedly refine the extraction process. A typical cycle involved exporting the raw first-pass data, analyzing the results with MS Copilot, asking for what noise was obstructing analysis, then creating targeted extraction scripts to remove the unwanted data, and running the process again.  This was repeated several times, with each step asking the AI to review the extracted data and provide feedback on whether the dataset appeared sufficiently refined for high-level analysis. The scripts progressively rolled the large volumes of infrastructure, application, and relationship data into smaller, consumable datasets. Additional passes were then used to correlate CMDB records with operational data such as incidents and support ownership.

Once the data was cleaned to a reasonable level, the combined datasets were submitted back to MS Copilot chat for first-pass, high-level analysis. The resulting findings were preserved and combined into a second-pass executive-level summary. The output identified major technology portfolios, high-level dependency patterns, ownership structures, and the systems that appeared most important to the organization. These findings were combined into a single document that contained both the executive-level summary and the more detailed breakdown of the technical components supporting business operations.

The final major area for me to understand was integrations.  The remaining question to answer was what information moves between ServiceNow and the rest of the enterprise ecosystem? Unlike the previous analyses, there was no single table capable of telling the entire integration story. And as a new team member without direct production admin access, the approach relied on examining the artifacts left behind by integrations in the DEV environment rather than observing the running integrations in production. Multiple datasets were extracted and reviewed by the AI, including Flow Designer actions and sub-flows, import-set tables, transform maps, data sources, scheduled imports, connection aliases, REST connection definitions, JDBC connections, MID server configurations, PowerShell assets, and IntegrationHub components.

The analysis began with Flow Designer assets. Using scripted extracts, AI was used to identify the non-standard actions that appeared repeatedly across flows. This process required multiple passes using scripting to clean the sys_hub_action_instance table extract to then reveal where integrations existed and which external systems appeared frequently in automation processes. From there, the raw table exports from the long list of integration related tables was pulled to understand how information entered and exited the platform outside of integration hub.

The Flow Designer action analysis, and integration related table extracts was combined  and submitted to the AI to produce the high-level executive summary and expanded integration component detail overview documents. By this stage of the process, I had a reasonably complete picture of the platform: what had been built, who used it, what broke, who supported it, what technology it depended on, and how it exchanged information with the rest of the organization.

None of the individual datasets provided a complete picture of the platform on their own. The value came from correlating everything together. Development history, operational data, organizational ownership, technology inventory, and integrations each contributed to a different piece of the story. Every mature ServiceNow instance contains years of decisions, processes, automations, successes, failures, and organizational history. I found the fastest way for me to derive quick insight into a system with minimal documentation available was to dig deep. Armed with a proverbial script shovel, a pile of extracted data, and a little bit of platform archaeology and a powerful AI chatbot, I was able to rapidly organize and make sense of the enormous volume of information hidden within a mature ServiceNow implementation.