Week 2 Is where ServiceNow stopped feeling liek "learn where the buttons are" and started to feel like "learn how Information actually moves through this system"
I circled back to the ACL lab from Module 4 (full write-up here) and pciked up two details that didnt't fully land the first time: ACLs evaluate from most specific to most general, and nothing touching them works without the elevated [security_admin] role. Small facts, but they explain a lot of "why didn't that work" moments.
This is ServiceNow's answer to "I have a spreadsheet for hardware, and I need It In the system correctly." Data lands In a staging table first, gets mapped field-by-field via a Transform Map, then moves to its real home. The part that actually made this click was coalesce- the field ServiceNow uses to decide, "Is this a new record, or an update to one that already exists?" Get the coalesce field wrong, and you either flood the table with duplicates or silently overwrite the wrong record. In Lab 4.3.1, I ran real HHD hardware data through the whole pipeline - source -> Import table -> transform -> transform -> target - and watching the full chain made every earlier piece finally make sense.
I also learned about coalesce fields, which was one of the more important concepts from the import process.
A coalesce field is used as a unique key during an import. ServiceNow uses that value to determine whether an incoming record should match an existing record or create a new one.
There are several ways coalescing can be configured, including:
Single-field coalesce
Multiple-field coalesce
Conditional coalesce
Understanding coalesce helped me see how ServiceNow can prevent unnecessary duplicate records while keeping imported information synchronized with existing data.
During Lab 4.3.1, I was able to put these concepts into practice by importing HHD hardware data.
As part of the lab, I:
Created a new list layout to prepare for the data import.
Created an Import Set Table.
Created a Transform Map.
Worked with multiple imports.
Transformed the imported data.
Cleaned up the imported data.
This was one of the more practical parts of the module because it allowed me to see the entire process rather than learning each component independently.
The lab helped connect the pieces:
Source Data → Import Set Table → Transform Map → Field Mapping → Transformation → Target Table.
Seeing this workflow in action made the data import process much easier to understand.
The Configuration Management Database is basically the org chart for technology - every server, app, firewall, and how they connect, stored as Configuration Items (CIs). I explored the CI Class Manager ( a tree view of how CI types inherit from one another) and the Dependency View, which turns a wall of Individual records into an actual map. When you click to open a CI and see what's connected, what's currently broken, and what else might be affected. The last part Is the whole point of a CMDB: If an app goes down, the CMDB is what tells you what else is about to.
Security protects the data. Tables organize it. Import Sets bring It In. The CMDB maps how it all connects. By the end of the week, these stopped feeling like separate topics and started feeling like one system.
As I continue through the RiseUp program, I want to move beyond memorizing ServiceNow terminology and focus on understanding why these features exist and how they solve real IT problems.
My goal is to build enough foundational knowledge to successfully pursue the ServiceNow Certified System Administrator (CSA) certification and eventually continue toward Certified Application Developer (CAD).
Week 2 gave me a much stronger foundation in ServiceNow administration, particularly around security, data management, imports, the CMDB, and configuration item relationships.
There is still a lot to learn, but I'm starting to see how the different pieces of the ServiceNow platform fit together—and that is what makes this journey exciting.