Someone hands you a login, calls it "the ticket system", and walks off. You open it and there are twenty modules, a thousand tables, and a scripting engine underneath all of it. This lesson removes about half of that confusion in one idea.
One database wearing many hats
Incidents, changes, requests, assets, HR cases: none of them are separate systems. They are records in tables, and most of the tables you will touch inherit from one parent table called Task. Learn Task and the platform stops being twenty products and becomes one product with twenty views.
Task carries the fields you keep seeing everywhere: number, short description, assigned to, assignment group, state, priority, opened, closed. A child table adds its own fields on top. Incident adds things like caller and category. Change adds risk and planned dates. Underneath, the shape is the same.
Why inheritance matters on day one
A field added to Task appears on every child table, which is why a small change can have a very wide blast radius.
A business rule written on Task runs for incidents, changes and requests. Write it on Task by accident and you have just changed the whole platform.
Reports and lists can run across Task, which is how you answer "what is assigned to this team" in one view instead of five.
Exercise: read the platform like a database
Open any incident record. Note five fields you can see.
Open a change record and a catalogue request. Find the same five fields there.
Write down which fields were shared and which were unique to one table. The shared ones are Task.
Now list every record assigned to your own user across Task, rather than opening each module one at a time.
Do that once and you will never again think of ServiceNow as twenty separate tools. Next lesson: reference fields and dot walking, and why the filter you just built returns the wrong rows.
Independent training. Not affiliated with, endorsed by, or a reseller of ServiceNow Inc.