Learning ServiceNow when you already run your own servers

New platform, new acronyms, surprisingly familiar ideas. Notes from working towards my ServiceNow CSA.

Sections (7)

I’m working through ServiceNow’s learning modules towards the CSA (Certified System Administrator) certification. Nobody asked me to. I find the platform genuinely fascinating, and the more I learn, the more it feels like somewhere I already know my way around.

What ServiceNow is

ServiceNow is a platform large organisations use to run their internal operations. When someone raises an IT ticket, requests a new laptop, reports a broken system or onboards a new starter, there’s a good chance it’s flowing through ServiceNow behind the scenes.

It’s big, it’s enterprise, and at first glance the acronyms alone could fill a dictionary. ITSM (IT Service Management), CMDB (Configuration Management Database), ACLs (Access Control Lists). But underneath, the core ideas are ones I’ve been working with for a while.

Everything is a table

The first thing that clicked: in ServiceNow, almost everything is a record in a table. An incident is a row. A user is a row. A laptop is a row. Relationships between them are references from one table to another.

That’s exactly how I built CrewSpace. Tasks, projects, users and companies all live in a PostgreSQL database, linked together. Different tools, same thinking. Understanding the data model is most of the battle, and I’ve fought that battle before.

Workflows feel familiar

ServiceNow’s Flow Designer lets you build automations: when this happens, do that, then check this, then notify someone.

I run n8n on my own server for exactly this kind of thing. Our LinkedIn posts publish themselves through an approval step. Our lead enrichment works through data sources in order until it finds an answer. Triggers, conditions, actions, approvals. Flow Designer puts it inside an enterprise platform, but the logic is the same logic.

Permissions are the same lesson

ServiceNow takes access control seriously, with ACLs checking who can read, write or delete each record, and even each field.

I learned why that matters building my own app: hiding a button isn’t security, and the server has to check every request. (Longer post on that here.) ServiceNow bakes that principle into the platform. It’s reassuring to see a system built by thousands of engineers land on the same rule I build my own app around.

Instances and infrastructure

In ServiceNow you work in instances, separate copies of the platform for development, testing and production. I’ve got my own PDI (Personal Developer Instance) to experiment in.

I already run Oracle Cloud servers, Docker containers, a mail server and self-hosted tools. Keeping development separate from production, being careful about what you change where, and not testing in the live system are habits I’ve already got. ServiceNow manages the infrastructure for you, but knowing what’s going on underneath makes the platform side feel much less mysterious.

The CRM angle

I’ve also self-hosted Twenty, an open-source CRM (Customer Relationship Management) tool, and our agency’s day job involves tracking leads and customers from first click to closed deal. ServiceNow’s customer service side covers similar ground at a much larger scale: cases, customers, service levels, escalations. The scale is new. The shape of the problem isn’t.

Where I’m at

Still learning, and enjoying it. The acronyms take time. The concepts don’t. Tables, workflows, permissions, environments and automation are things I’ve already built with my own hands on my own servers.

ServiceNow is a bigger, more structured version of a world I already live in. That’s exactly why I want to get properly good at it.