Beyond Ticketing: ServiceNow as Your Infrastructure Automation Hub

In the infrastructure engineering world, there are few things that elicit as many deep sighs as ServiceNow–second only to the coffee machine going down, maybe?

It’s often seen as a bloated platform used only for ticket management and the dreaded change request process. But, after more than nine years in infrastructure engineering across multiple enterprises, I’ve come to love and appreciate ServiceNow’s potential as a powerful automation hub. When properly leveraged, it transforms the cumbersome ticketing system into a robust platform for infrastructure orchestration, compliance automation, and self-service IT operations. Here’s how I’ve turned the platform everyone loves to hate into the backbone of an infrastructure automation strategy.

The Infrastructure Engineer’s Dilemma

Enterprise tools come with a slew of issues; they’re slow, expensive, and overly complicated with a giant list of features that mostly go unused. ServiceNow is no exception to this. The amount of tables, features, Flows, Service Catalog request items, etc. is overwhelming and does take some getting used to.

It’s easy to get upset with ServiceNow because it acts as the single front-end for such a large collection of “tools”/“features”. Infrastructure tooling tends to be an ecosystem with various interconnected services working together to achieve a task. A deployment pipeline might consist of a GitHub repo triggering a Jenkins pipeline which pulls down some Terraform modules that then go on to create or modify some infrastructure in AWS. There’s no one “thing” to blame in this ecosystem, aside from developers rightfully complaining that deployments take too long.

But this ecosystem of interconnected tools comes with a hidden cost: fragmented tooling. How does a new employee request a laptop? That’s a form in ServiceNow, of course! But how does a developer request a new Jenkins repo? That’s a Jira ticket. What about a new Artifactory repo? That’s a Slack Workflow. New GitHub repo? Why, that requires sending the infra team an email, duh! Documenting all of this information is easy, at first! The real technical debt comes from keeping the documentation up-to-date as team members come and go.

Shifting Perspective: ServiceNow as the Single Source of Truth

My opinions on ServiceNow truly shifted when I began seeing the platform as the Single Source of Truth (SSOT) for everything in an enterprise environment. I implemented ServiceNow as the SSOT at a previous role as a Sr. DevOps Engineer and it had some incredible benefits. One of the benefits was that teams got accustomed to looking in ServiceNow for almost all infrastructure requests. If they need to create an Artifactory Repo, there’s a catalog request item for that in ServiceNow. A new AWS account? ServiceNow. New Github repo? ServiceNow. What about requesting a new Splunk Index? That’s a Jira tic–just kidding, the answer is always ServiceNow. This meant engineers on the infrastructure team had more time to focus on their work as there were fewer questions on Slack, and our Jira board was significantly cleaner as there were no more tickets for new infrastructure requests from other teams. This also simplified things for the development teams. There’s no longer confusion as to how to request something new; the answer is always ServiceNow.

Another benefit to this paradigm is figuring out who to reach out to when something goes wrong. I once noticed one of our Artifactory instances was experiencing a massive spike in CPU usage. I looked into the logs and found that a service account was spamming requests for an artifact in a poorly named Artifactory repo. I looked up the service account in Confluence and found no documentation relating to the account. I then looked up the repo name in ServiceNow. It turns out the repo had been created using a form in ServiceNow. I then had access to the name of the person that requested the repo, the name of their manager, their Cost Center, the person from the Finance Team that approved the service, the department name, etc. This made it easy to know who I needed to reach out to in order to figure out why the service account was spamming requests to Artifactory, and the issue was resolved in less than an hour. This would’ve required an “@everyone” in a Slack channel at other companies.

Automation Takes Priority

At a previous role, I engineered a serverless automation platform consisting of AWS API Gateways, Lambdas, Step Functions, and DynamoDB. I then wrote all of our team’s automations on this platform, starting with Artifactory repo creation. An API endpoint was created, /api/create_repo, which would call a repo creation Step Function, which would then trigger a number of Lambdas. One Lambda would pull the HTTP endpoints for all of our Artifactory instances (9+ across 5 environments; 2 sandboxes, dev, staging, and prod), the next Lambda would go through the list and use Artifactory’s REST API to create the requested repo. The final Lambda would then configure replications between instances in the different environments. This automation was needed not just because of how many Artifactory instances we had, but also because we had engineers all across the globe. Before I implemented this automation, a team in Asia would request a repo but the repo would not be created until the US-based infra team woke up; by the time it was actually created, the team in Asia was already asleep. This meant fulfillment for such a simple request would practically take 24+ hours. This turnaround time would be even greater if there was a US holiday that wasn’t shared by the teams working in Asia. Our company also had teams in London, Israel, Australia, etc. all of whom experienced longer wait times because the infra team was located in the US.

Other processes I automated through the platform:

• AWS Account Creation (we had thousands of AWS accounts)
• Artifact promotion from dev to prod
• Compliance enforcement within Artifactory
• Managing SSO group access in Artifactory
• Jenkins Repo Creation

The platform itself was cost-effective; total costs ranged from $30 a month up to $50 depending on how many requests it handled over the course of the month. Because it ran on AWS serverless components, there was never any patching required and most of the work involved was focused on automating more processes rather than managing the platform itself.

Connecting ServiceNow to the Automation Platform

My ServiceNow automations always began with a Service Catalog item. There was a form for everything. For example, there was a form for creating an Artifactory repo titled “Create an Artifactory Repo.” This made it easy for end users to find all of our Artifactory-related forms; all they had to do was type “Artifactory” into the search bar in ServiceNow.

The form for Artifactory repo creation had two simple fields: Service Name, and Repo Type. The repo type field was a drop-down menu containing only valid Artifactory repo types, e.g. “generic,” “maven,” and “docker.” Forms always required approval, but the approval went to the requesting user’s manager, not to the infra team. Repo names could be standardized by combining the Service Name with the repo type to form the repo name, for example “WEBAPP-generic.” The form being only two fields also made it simple for end users to request a new repo in Artifactory. They did not have to know what a valid repo type is in Artifactory, they didn’t have to know which infra team was responsible for Artifactory, they didn’t even have to know how to find the repo they just requested! The automation platform would return the full URL to their new repo once it was created, and this information was added to the Service Catalog item’s notes.

Finally, because all Artifactory-related automations were orchestrated through ServiceNow, the form to create an Artifactory repo also triggered an API request to add the requester’s SSO group to the repo’s permissions, automatically giving them read and write access to the repo the team requested. This meant one less form for teams to have to deal with, and it meant less work for my infra team.

Tying the Service Catalog item to the automation platform was slightly complicated. Each Service Catalog item was tied to a Workflow in ServiceNow: Classic Workflows.

Workflows were fairly simple, and they all had a script component written in Javascript that would gather the required information from the catalog item and package it into a REST API call to the automation platform. The workflow would then public notes to the catalog item informing the user that their requested resource was completed, and the workflow would then be responsible for closing out the catalog item after marking it as complete.

Here’s how to trigger a Classic Workflow with a Service Catalog item: Trigger a Workflow from a Service Catalog Item

This process did have some downsides. There was no easy way to pull script code from GitHub, so when I wanted to make changes to a Workflow’s code, I would write the code first on my local machine, then I would push the changes to GitHub and have the code reviewed, and finally I would copy the code from GitHub into the Workflow UI. This made it difficult to enforce GitOps principles because in theory, I could write new script code into the Workflow and the GitHub repo would be none the wiser.

Another downside was that other services besides ServiceNow could make API calls to the automation platform. This required being diligent about who had API keys to the platform and what they did with them. Our CI/CD pipeline could request artifact promotion from dev, all the way up to prod, outside of ServiceNow, but it did not have access to any other API paths (e.g. repo creation).

It’s Still Not Easy!

Using ServiceNow as the Single Source of Truth does make a lot of things easier, including infrastructure automation, but it’s still not a one-click fix-all for everything. It still requires buy-in from everyone at the company, and it still requires an obsession with automating everything.

But engineers on an infra team shouldn’t be getting bombarded with requests for infra-related tasks and questions about where-is-this-form and how-do-I-request-that. Using ServiceNow as a front-end for automation frees up the infra team to focus on automating as many tasks as possible and it allows development teams to take advantage of those automation tasks quickly and easily.