ishenwei/nexus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
nexus/knowledgebase/course-notes/ServiceNow-Basic-Administration-Notes.md

79 KiB
Executable File
Raw Permalink Blame History

ServiceNow: Basic Administration — Course Notes

Source: LinkedIn Learning — ServiceNow Basic Administration (updated 2025-08-01) Total: 9 chapters / 26 videos Extracted: 2026-09-19

Chapter 1 — 1. Administering ServiceNow

Core Insights

  • ServiceNow is transforming how organizations manage IT and business services, and its rapid evolution (latest Yokohama release) makes administration skills essential for modern IT operations.
  • This course delivers hands-on experience with the core administrative tools of the platform.
  • Focus applications covered include the Configuration Management Database (CMDB), the Knowledge Base, and the Service Catalog.
  • The goal is to learn how to configure, manage, and optimize ServiceNow — a core competency for enterprise IT roles.

Detailed Notes Platform evolution

  • ServiceNow changes quickly; the course is framed around the latest release (Yokohama), showing administration is an ongoing, current skill. What admins manage
  • CMDB: configuration management database holding IT infrastructure and service relationship data.
  • Knowledge Base: centralized repository for articles, self-help content, and internal documentation.
  • Service Catalog: user-facing catalog of requestable services and catalog items. Course approach
  • Emphasis on "hands-on experience" with core administrative tools rather than pure theory.

Action Items

  • Identify where each of the three core applications (CMDB, Knowledge Base, Service Catalog) lives in your own ServiceNow instance.
  • Skim the ServiceNow Yokohama release notes to understand what has changed in the current release.
  • Set a target: be able to navigate and administer each core application confidently by the end of the course.

Key Terms/Concepts

  • CMDB (Configuration Management Database): the ServiceNow application that stores configuration items and their relationships.
  • Knowledge Base: a structured library of articles and documentation for knowledge management.
  • Service Catalog: the module where end users request services and where admins manage catalog items.
  • Yokohama release: the current ServiceNow platform release referenced by this course.

Chapter 1 — 2. Setting up for success

Core Insights

  • Separate dev, test, and prod environments and practice in a personal developer instance where mistakes cost nothing.
  • Keep the omnipotent (full-access) admin account separate from day-to-day platform owner duties; use different accounts for different roles.
  • Capture a clean baseline, enable audits, and schedule update set backups before making changes; take snapshots before experimenting.
  • Resistance to over-customization: keep plugins lean, names predictable, and every configuration tied to a real business outcome.
  • Think in end-to-end processes, partner with stakeholders, and document decisions so future admins can follow your logic.

Detailed Notes Environment strategy

  • Treat dev, test, and prod as distinct, "well-lit hangars" — setting this up once makes every later change smoother.
  • Practicing in a personal development instance (PDI) means crashes cost nothing. Account hygiene
  • Keep the omnipotent admin account separate from day-to-day platform owner duties; have different accounts going for different work. Safety nets
  • Run admin like a pilot's checklist: capture a clean baseline first.
  • Enable audits and schedule update set backups so nothing is lost.
  • Take snapshots before experimenting with new features or making big changes — "snapshots beat regrets." Business mindset
  • Administrators shape how the business works, not just fill out forms; every field tweak ripples through satisfaction scores, audit trails, and compliance.
  • Partner with stakeholders and leave documentation "breadcrumbs." Restraint and iteration
  • Customization power is a double-edged sword — resist customizing every screen.
  • Build in the personal developer instance, measure the gains, refine, then roll out to production.

Action Items

  • Create or verify distinct dev, test, and prod environments (or a personal developer instance) before touching production.
  • Set up separate accounts: one omnipotent admin, one for day-to-day platform ownership.
  • Enable audit logs and schedule update set backups on your instance.
  • Take a snapshot of the current baseline before your first experiment.
  • For each planned change, write out the business outcome it serves and document it for the next admin.

Key Terms/Concepts

  • Personal Developer Instance (PDI): a free, private ServiceNow instance for safe practice.
  • Update set: a container that groups changes for controlled migration between environments.
  • Baseline: a recorded clean starting state to compare against after changes.
  • Omnipotent admin: the full-privilege admin account, best kept separate from day-to-day duties.

Chapter 1 — 3. What you need to know

Core Insights

  • ServiceNow is a cloud platform that runs digital workflows and speaks its own vocabulary; once the core terms click, roughly half the platform's mystery disappears.
  • The fastest way to learn is to play safely in a free personal developer instance (PDI), which is almost always on the newest build.
  • ServiceNow releases twice a year, named after cities (e.g., Zurich); fundamentals survive every upgrade, so watch release notes rather than panic.
  • The course is built like Lego bricks: each video stands alone, but together they form a solid structure — concept primer, on-screen walkthrough, and a best-practice nugget per video.

Detailed Notes Core vocabulary (the platform "dialect")

  • Tables = spreadsheets; records = rows; forms or lists = the UI layered on top.
  • Modules bundle those screens into apps — so "incident" is not magic, just data plus views. Learning environment
  • Grab a free personal developer instance on the ServiceNow developer site.
  • In that walled garden you can create fake users, "blow up" ACLs, and practice Flow Designer without triggering compliance emails. Release cadence
  • Twice-yearly releases named after cities; example given is Zurich-ready features.
  • Keep an eye on release notes and lean on community threads to treat version shifts as routine maintenance. Course structure
  • Each lesson: quick concept primer → on-screen walkthrough → actionable best-practice nugget.

Action Items

  • Claim your free personal developer instance from the ServiceNow developer site before the next lesson.
  • Test drive what you learn after each video — theory is good, muscle memory is better.
  • Bookmark the ServiceNow release notes and community forums to stay current on version changes.

Key Terms/Concepts

  • Table: ServiceNow's data container, comparable to a spreadsheet.
  • Record: a single row of data in a table.
  • Form/List: the user interface layered on top of table data.
  • Module: a bundle of screens that make up an application.
  • PDI (Personal Developer Instance): free ServiceNow instance for safe, hands-on practice.
  • ACL (Access Control List): rule that governs who can read/write records — safe to experiment with in a PDI.

Chapter 2 — 1. Navigating the UI: Apps, menus and modules

Core Insights

  • The Next Experience UI has three zones: the banner (top), the Application Navigator / All menu (left), and the content frame (center).
  • Global search (Ctrl-Alt-G) finds any record instantly; the globe icon shows your application scope and update set so changes land in the right place.
  • Favorites, History, and shortcuts (Ctrl-Alt-A) let you move through the platform without hunting through menus.
  • Impersonate User and Elevate Roles are admin-only tools for testing access as someone else or temporarily granting security-admin rights.
  • Help, bell, and sidebar icons add contextual help, notifications, and record-level collaboration (sidebar is new in Yokohama).

Detailed Notes The Banner

  • Logo click returns home; five menus: All (full app/module list), Favorites (bookmarked modules), History (recently accessed items), Workspaces (entry to CSM/ITSM/Process Mining), Admin (appears with elevated roles).
  • Center of the banner shows the current module and record; the global search bar sits on the right (Ctrl-Alt-G; searches live tables like Incident, Problem, Task, Request).
  • Globe icon = application scope and update set picker; changes save into the current scope, and a wrong scope means updates land in the wrong place or not at all.
  • Sidebar: discussions tied to a workspace record, @mentions, file sharing, knowledge-base article links, pin/favorite discussions (new in Yokohama; works in ITSM/CSM/HR workspaces).
  • Help icon shows contextual articles (definitions, instructions, best practices); bell icon shows notifications.
  • User menu: Profile (details/password), Preferences (themes, accessibility options), Keyboard shortcuts, Impersonate User (red screen and red avatar indicate browsing as someone else; End Impersonation exits), Elevate Roles (temporary security-admin privileges, e.g. for access control or background scripts).

Application Navigator (All menu)

  • Left side, minimized by default; click to expand; pin icon keeps it open while working.
  • Apps are grouped by function; click to expand/collapse modules; filter field narrows results (typing Change pulls up Change Management).
  • Star any module to add to Favorites; X removes favorites; edit-module icons customize name, visibility, ordering, and roles.
  • Shortcut: Ctrl-Alt-A then Tab jumps straight into the filter field.

Content Frame

  • Large central workspace where selected modules open — e.g. clicking Open Incidents shows a list view here.

Action Items

  • Identify the banner, Application Navigator, and content frame in your own instance.
  • Practice global search with Ctrl-Alt-G on a known record number.
  • Check the globe icon before configuring: confirm the correct application scope and update set.
  • Review Keyboard shortcuts in the user menu and try Ctrl-Alt-A + Tab into the navigator filter.
  • Use Impersonate User to view a form as a limited user, then End Impersonation.

Key Terms/Concepts

  • Banner: top bar with logo, navigation menus, search, scope indicator, and user options.
  • Application Navigator / All menu: left-hand menu listing applications (groups) and modules (entries).
  • Content frame: central area where selected modules and records render.
  • Application scope: context that determines where configuration changes are saved.
  • Impersonate User: temporarily browse the platform as another user to test access.
  • Elevate Roles: temporarily grant security-admin privileges for critical admin tasks.

Chapter 2 — 2. Customizing the Application Navigator

Core Insights

  • Applications are the folders of the navigator; modules are the links inside them. If a user cannot see the application, its modules stay hidden too — unless Override Application Menu Roles is checked.
  • Targeted modules can show filtered record lists to specific roles, e.g. Overdue Incidents visible only to the service desk.
  • Hiding an app or module is reversible: unchecking Active removes it from view without deleting any data.
  • Best practices: group modules by task, use verb-first labels, and order items in increments of 20 so future additions are easy to slot in.

Detailed Notes Building blocks and the golden rule

  • Applications (Incident, Problem, Change) = folders; modules (Create New, Assign to Me, Open, Resolved) = links inside the folders.
  • Golden rule: a hidden application hides its modules, unless the edit-module option Override Application Menu Roles is enabled.

Creating a targeted module (Overdue Incidents)

  • Path: Navigator → System Definition → Application Menus → search Incident → open the Incident application → New Module.
  • Title: Overdue Incidents; application menu: Incident; link type: List of Records from the incident table; filter by due date before (prior to) today.
  • Visibility: assign roles that control who sees the module (ITIL covers service desk agents).
  • Order: 120 = second item in the list; use increments of 20 (100, 120, 140) so a future item (e.g. 111 or 119) can be slipped in without renumbering.

Hiding modules

  • Edit module → uncheck Active: like a light switch — no data loss, and the item disappears for users.

Best practices

  • Group modules by task rather than by department.
  • Naming: verb-first labels such as Approve Changes instead of Approvals.
  • Admins can create hidden menu items through the System Properties module.

Action Items

  • Create a new module under an existing application that shows a filtered list for one role.
  • Restrict visibility with role-based settings, e.g. ITIL for service desk agents.
  • Deactivate a module you no longer need and confirm it disappears for users while data stays intact.
  • Renumber module priorities using increments of 20.
  • Rewrite at least one module name with a verb-first label.

Key Terms/Concepts

  • Application: top-level navigator folder grouping related modules.
  • Module: navigator entry pointing to a list, form, report, or record.
  • Override Application Menu Roles: checkbox letting a module stay visible even when its parent application is hidden.
  • Link type: defines what a module opens (e.g. List of Records with a filter).
  • Role visibility: roles that determine which users see a module.

Chapter 2 — 3. Understanding tables and records

Core Insights

  • ServiceNow data is organized into tables (containers), records (rows), and fields (columns); labels are user-facing while the dictionary keeps technical names.
  • Tables inherit from parents: Incident extends Task, so it automatically receives every Task field — update the parent once and all children inherit the change.
  • Tables live under System Definition → Tables, where the Extends Table field and Schema Map visualize inheritance.
  • Field properties (defaults, mandatory, dynamic logic) and dictionary label overrides make forms intuitive and data clean without touching code.

Detailed Notes Database pillars

  • Tables group similar data (incident holds tickets, sys_user stores people); records are individual rows (a single ticket, e.g. inc001); fields are columns (short_description, assigned_to); labels are what users see (Urgency) while the dictionary holds the technical name (priority). Excel analogy: worksheet = table, row = record, column = field, cell = value.
  • The dictionary is the source of truth defining every table and field rule.

Inheritance

  • Parent tables hold universal fields (assigned to, due date on Task); child tables (Incident) add their own (priority, impact) and inherit the rest — no reinventing the wheel.
  • How to see it: System Definition → Tables → search Incident → open the table → Extends Table shows Task; Show Schema Map expands Incident columns plus inherited Task columns (due date, assigned to, description).
  • Payoff: one report on the parent Task table automatically covers all child tables (incident, problem, change).

Field types and properties

  • Reference fields link to another table (assigned_to → sys_user); choice fields are drop-downs (priority: high/medium/low) that prevent typos; date/time fields have calendars and can auto-calculate (due date = created + 2 days).
  • Default values: set urgency to always default to 2 (medium). Mandatory flags: block saving when a critical field (e.g. channel) is blank. Dynamic logic: show/hide fields by condition (approval notes only when priority is high).

Configuring labels and fields

  • Right-click a field label → Configure Dictionary: the control panel for every field. The Label tab supports per-table labels — add Incident → Incident Description while the backend keeps short_description, so automations, code, and APIs stay intact.
  • Faster path for next time: right-click → Configure Label (skips the dictionary view).
  • Shortcuts: form header (three lines) → Configure → Table teleports to the table definition; System Definition → Tables → your table → Fields lists every field including hidden ones.
  • sys_ tables (sys_user, sys_group) are core building blocks: pre-optimized, used across all applications, never deleted during upgrades — always check for an existing sys_ table before building anything custom.

Action Items

  • Open System Definition → Tables, search incident, check its Extends Table value, and view the Schema Map.
  • Repeat for the problem table and spot its inherited fields (practice for change request too).
  • From any form, use the three-line menu → Configure → Table to reach the underlying table definition.
  • In your instance, set a default value and a mandatory flag on a field via Configure Dictionary.
  • Add a per-table label (e.g. Incident Description for short_description on Incident) and verify it displays without renaming the backend field.
  • Before building any custom table, search for an existing sys_ table that already covers the need.

Key Terms/Concepts

  • Table: container for records of similar type, defined in System Definition → Tables.
  • Record: a single row/entry in a table.
  • Field: a column holding a specific attribute.
  • Dictionary: technical registry of every table and field, including its rules.
  • Label: user-facing field name, changeable without affecting the dictionary name.
  • Parent/child table: inheritance relationship where children automatically receive parent fields.
  • Extends Table: field showing which parent a table inherits from.
  • Reference field: links records across tables (like a hyperlink).
  • sys_ tables: ServiceNow core tables, pre-optimized and upgrade-safe.

Chapter 3 — 1. Managing users groups and role-based access control RBAC

Core Insights

  • Users, groups, and roles are the three pillars of ServiceNow access: users are people who need platform access, groups are collections of users sharing a function, and roles are access-control labels defining what can be read, written, or approved.
  • RBAC is the foundational principle: never assign roles directly to users — assign roles to groups, then add users to groups, so access scales and administration stays simple.
  • Administering RBAC (creating users/groups, assigning roles) requires the user admin role; without it those modules are read-only.
  • Users can belong to multiple groups; groups can be organized into parent-child hierarchies.
  • The Access Analyzer Suite (Analyze Permissions: Compare Users + Access Simulator) lets you test and compare access without logging in as different users.

Detailed Notes User and group creation

  • All menu (Ctrl+A) → type "users" → User module → New to create a user (e.g., ServiceDesk Steve), Submit to save.
  • Create groups via All menu → Group app → New; set a manager (e.g., Abraham Lincoln) and description; optionally make the group a member of a parent group for organization.
  • Add a user to a group from either side: open the user record → Groups tab → Edit → Slushbucket search → double-click to add → Save; membership updates are queued asynchronously and complete on page reload.

Role assignment

  • Open the group record, verify members on the Group Members tab, then Roles tab → Edit → use the Slushbucket to select roles (e.g., knowledge, password_reset) and Save.
  • Each assigned role carries metadata like created date — useful for audit tracking.
  • Users inherit all access purely from their group membership (Steve gets knowledge + password reset via Tier 2 group).

Access Analyzer Suite

  • Compare Users: compare two users (e.g., David Liu vs. ServiceDesk Steve) across tabs like Groups to find missing memberships causing access errors.
  • Access Simulator: simulate adding/removing a role or group and see whether a table/resource access would be allowed or denied — great staging before production changes and for complex role setups.

Action Items

  • Assign roles to groups, not individual users; add users to groups instead.
  • Verify group membership before editing roles: check Group Members tab first.
  • Use Access Analyzer → Compare Users when troubleshooting a user's access vs a peer.
  • Use Access Simulator to stage role/group changes before applying them in production.
  • Confirm your own account holds the user admin role before attempting RBAC admin tasks.

Key Terms/Concepts

  • User: Anyone needing platform access; permissions define what they can create, view, or modify.
  • Group: A collection of users sharing a common function (incident managers, service desk agents); supports parent-child organization.
  • Role: An access-control label determining read/write/approve permissions for a user or group.
  • RBAC (Role-Based Access Control): Assign roles to groups, users to groups — the standard ServiceNow security model.
  • Slushbucket: A two-pane picker dialog for selecting/moving items (users, roles) between lists.
  • Access Analyzer Suite: Tools to analyze permissions, compare user access, and simulate record changes' access consequences.

Chapter 3 — 2. Securing access with access control lists ACLs

Core Insights

  • ACLs (Access Controls) are the gatekeepers of a ServiceNow instance — they define who can view, edit, or delete records, protecting anything from a single field to an entire application.
  • Permission flow follows the same rule as RBAC: roles → groups → users, never permissions directly on users.
  • ACLs enforce security through three sequential checks — required role, condition, then script — and deny access immediately if any check fails.
  • Always grant application menu access too; without it users cannot even see the modules, even if ACLs allow field edits.
  • Best practices: least privilege, test conditions thoroughly, audit ACLs quarterly, and document complex rules.

Detailed Notes How ACLs work

  • Three ordered checks: (1) user has the required role → (2) conditions pass (e.g., record is in draft state) → (3) optional scripts run for complex logic; any failure denies access immediately for performance.
  • ACL scope ranges from a single field up to a whole application.

Worked example: problem statement coaches

  • Create the role (System Security → Roles → New → "problem statement coach").
  • Create a group (User Administration → Groups), assign the role via the Roles tab, add members via Group Members (e.g., Abraham Lincoln, Andrew Jackson).
  • Elevate role temporarily (profile icon → Elevate Role → check security_admin → Update; screen turns red while elevated) because security lists need elevated privileges.
  • Edit ACLs: System Security → Access Control; find the field ACL (problem.short_description, then problem.description); in "requires role," add the coach role next to existing SN problem write role; Update.
  • Add the coach role to the Problem application menu module access (Application Menus) so coaches can actually see the modules.

Testing

  • Always test ACLs with real users — elevate your role and impersonate that user to verify access without unintended exposure.

Action Items

  • Build roles first, then groups, then attach members — never assign ACLs straight to users.
  • Elevate role when editing security lists; remember the red screen indicates an active elevation.
  • Add the new role to both the field/table ACLs AND the application menu access.
  • Test every ACL by impersonating a real target user after changes.
  • Schedule quarterly ACL audits and document the purpose of complex conditions/scripts.

Key Terms/Concepts

  • ACL (Access Control List): Defines who can perform actions (view/edit/delete) on records or fields.
  • Requires Role: The role check an ACL enforces first before any further evaluation.
  • Condition: A rule (e.g., record state = draft) that must pass after the role check.
  • Script: Optional complex logic evaluated last for advanced access decisions.
  • Least Privilege: Granting no more access than a user needs to do their job.
  • Elevate Role: Temporary privilege escalation for admins, shown by a red screen banner.
  • Impersonation: Acting as another user in-session to validate their real-world access.

Chapter 4 — 1. Designing list views that work

Core Insights

  • Personalized list views let a single user rearrange columns (add, reorder, remove) without affecting anyone else; the gear icon shows a dot when a personalized view is active.
  • Admins can change the system-wide default list layout for all users via List Layout Configuration, including pulling in fields from related tables (shown in green).
  • Admin layout changes only affect users who haven't personalized their own view; personalizers must manually reset to see admin updates.
  • Modern lists (Yokohama release onward) support context actions — inline quick actions like copy record URL, open chat, or highlight a record without leaving the list.
  • Resetting a personalized view back to defaults is one click and restores the shared layout.

Detailed Notes Personalizing your own view

  • Open a list (e.g., Open Problems) and click the gear icon near the top right to open the personalization dialog.
  • Left panel = available fields, right panel = currently visible columns; double-click a field (e.g., urgency) to add it.
  • Use the up arrow to reposition columns (e.g., move urgency to second position, right after number), then click OK — the view updates immediately.
  • A small dot on the gear icon indicates the view has been personalized; choosing "reset to column defaults" clears it.

Changing the default layout for everyone

  • Right-click the list header → Configure → List Layout to open the admin-level configuration screen.
  • Unlike personalization, it can add fields from related tables via the plus icon and relationship icon (e.g., department/location from the Assigned To user record); related tables appear in green text, the base table in blue.
  • A view name dropdown targets changes to default, mobile, or workspace views; leaving it on default applies to most users.
  • After saving, urgency appears in the second column for all users who haven't personalized their view.

Context actions and modern lists

  • Introduced in the Yokohama release: context actions are quick actions that appear directly in list views (copy record URL, start a chat, highlight a record).
  • Commonly surfaced in specialized workspaces (service operations, portfolio planning); developers can customize them, admins mainly need awareness.

Action Items

  • Add urgency to the Problems list and reposition it to the second column to test personalization (watch for the gear dot).
  • Practice resetting a personalized view to column defaults.
  • In an admin/test instance, use List Layout Configuration to add a related-table field (e.g., assignee department) to a list and save to the default view.
  • Verify that a user with a personalized view does NOT see the new admin layout until they reset.
  • Familiarize yourself with context actions available in lists on your instance's release.

Key Terms/Concepts

  • Personalized view: A user-specific list layout; only the owner sees it, indicated by a dot on the gear icon.
  • List Layout Configuration: Admin tool (right-click header → Configure → List Layout) to set the system default columns for all users, including related-table fields.
  • Related table fields: Fields from linked records (green labels) that can be surfaced as extra columns in a list.
  • View name dropdown: Selects which view (default, mobile, workspace) an admin layout change applies to.
  • Context actions: Inline quick actions in lists introduced in the Yokohama release (copy URL, chat, highlight) for faster work without opening records.

Chapter 4 — 2. Optimizing form layouts and fields

Core Insights

  • Individual users can personalize a form via the sliders icon to show/hide fields — changes apply only to them, but there is NO visual indicator unlike lists, so forgetting is easy.
  • Form Builder is the admin tool for team-wide form redesign: drag-and-drop layout, real-time preview, field creation, and a configuration panel for behavior, layout, and access.
  • Sections can group related fields; tabs support single- or two-column layouts toggled from the configuration panel.
  • New fields (e.g., a currency field like "Cost of Service") can be created inline in the fields panel and dragged into the form.
  • Related Lists lets admins add related records as tabs below the form (e.g., incidents by the same caller) for a full record picture without separate lookups.

Detailed Notes Personalizing a form for yourself

  • Click the sliders icon at the top of a form to see which fields are visible vs. hidden.
  • Hovering over a field in the list highlights its position on the form; check/uncheck boxes to show or hide fields.
  • Customizations are private ("cleaning up your own desk"); the reset option returns everything to defaults.

Form Builder for team-wide layouts

  • Access: right-click the form header → Configure → Form Builder; offers modern drag-and-drop with a real-time preview.
  • Field panel on the left adds or creates fields; configuration panel defines behavior, layout, and access.
  • Move fields by dragging (e.g., priority to the top); click a field's X to remove clutter.
  • Adding sections requires switching scope to the application scope, then using the component selector to drag the form and drop a section (e.g., a "Metrics" section for actual start, actual end, resolve time).
  • Sections are flexible by default; use the layout toggle to switch tabs between single and two columns.
  • Create new fields with the fields panel button (e.g., "Cost of Service" with currency type), then drag the new field into the section; supported types include choice, reference, date, time, Boolean, and more.
  • Save the layout, return to the record form, and refresh to see the new section live at the bottom.

Adding related lists

  • Right-click header → Configure → Related Lists to pick which related records appear as tabs below the form.
  • Example: adding "Incidents by Same Caller" reveals repeat reporting by the same person (e.g., David Miller) without opening separate records.

Action Items

  • Personalize a form with the sliders icon, hide a noisy field, then reset to defaults; note there is no indicator that customization is active.
  • In a sub-production instance, open Form Builder and drag priority to the top of the form.
  • Create a new section (switch to application scope first), add a two-column layout, and populate it with a newly created currency field.
  • Add a related list tab (e.g., incidents by same caller) via Configure → Related Lists and verify it renders below the form.
  • Always test form layout changes in a sub-production environment before applying at scale.

Key Terms/Concepts

  • Sliders icon: Form personalization control for show/hide of fields, per-user only, reset via the reset option.
  • Form Builder: Admin drag-and-drop tool for redesigning form layouts with real-time preview, field creation, and configuration panel.
  • Section: A grouped area on a form, added from the component selector; toggleable between single and two columns.
  • Related Lists: Configured tabs below a form showing linked records (e.g., incidents by the same caller).
  • Field types: Choice (predefined options), reference (link to other records), date, time, Boolean, currency, etc.

Chapter 5 — 1. Managing tasks and approvals

Core Insights

  • Assignment rules (a type of trigger rule) evaluate record conditions and automatically route work to the right person or group, eliminating manual triage.
  • User presence shows who is viewing a record in real time; Sidebar Discussions provides embedded chat with search, KB, and Teams/Slack integration in Next Experience Workspaces.
  • State flows formalize record lifecycle transitions and auto-generate WorkNotes that document why a state changed.
  • Visual task boards (VTBs) turn incident/change/approval lists into interactive Kanban boards; dragging a card updates the actual record field.

Detailed Notes Assignment rules & trigger rules

  • Navigator: type "assignment" → System Policy → Rules → Assignment module; example rule "High Priority for Network."
  • Watched table = incident; "When to activate" tab checks high-priority/critical incidents in the network category.
  • Actions: assign to Network Support group; trigger action = Workflow (runs "On-Call Escalations by Email").
  • That workflow checks if an on-call schedule is active, logs the escalation, checks for an available on-call person, runs a parallel flow (alerts, email, SMS, app notifications), logs escalation end, verifies assignment success, and loops to escalate further if it failed.

User presence

  • Avatars + user count appear on forms when multiple people view a record; hover shows who's online.
  • Status dots: green = online, orange = recently logged out, no dot = offline; initials shown if no profile photo.
  • Presence also surfaces in VTBs, activity streams, form headers, and Connect Chat (typing/reading indicators).
  • Powered by Core UI; refreshes every 2 minutes by default (admin-configurable).

Sidebar Discussions & state flows

  • Sidebar works in ITSM Manager, CSM Configurable, and HR Agent workspaces; features search, pin, filters (All/Unread/This Record/Mentions), favorites, emoji, attachments, quick actions, and a summarize + search-KB action.
  • Messages can be edited/deleted/posted to activity stream; dock up to 25+ discussions; integrate with Microsoft Teams/Slack via Conversational Interfaces settings.
  • State flows: transitions (e.g., active→awaiting info, in progress→closed) can trigger notifications and child tasks and log WorkNotes (e.g., "rejected by agent," "no user response, closed by system after 72 hours").

Visual task boards

  • Create: Application Navigator → Visual Task Boards → New → data-driven board → table incident → vertical lane = state → optional swim lane = assignment group/priority → filter active=true.
  • Drag-and-drop between columns instantly updates the record's state field; works for problems, change, requests, and custom task tables.
  • Admins build team boards; users build personal boards for triage by priority or load balancing by assignment group.

Action Items

  • Create an assignment rule for a high-impact category and verify the triggered workflow escalates correctly after hours.
  • Configure Core UI presence refresh interval if 2-minute latency matters.
  • Enable Sidebar Discussions for your main workspace; set up Teams/Slack integration if your teams use them.
  • Build a VTB (state as vertical lane, assignment group or priority as swim lane, active-only filter) and use drag-drop in a stand-up.
  • Standardize WorkNote usage so state changes are always explained.

Key Terms/Concepts

  • Assignment rule: rule that evaluates record conditions and auto-routes work to a person/group.
  • Trigger rule: mechanism that launches workflows/actions when conditions are met.
  • User presence: real-time indicator of who is viewing a record (powered by Core UI).
  • Sidebar Discussions: embedded real-time collaboration chat in Next Experience Workspaces.
  • State flow: defined transitions guiding a record through its lifecycle.
  • WorkNotes: auto-generated messages explaining why a record changed state.
  • Visual task board (VTB): Kanban-style board over a task table, grouped by fields like state or priority.
  • Swim lane: optional horizontal grouping (e.g., assignment group, priority) on a VTB.

Chapter 5 — 2. Configuring notifications

Core Insights

  • Notifications are event-driven: when an action happens (reassignment, status change), ServiceNow logs an event; if a matching notification rule exists, it sends email, SMS, or Teams messages.
  • System Logs lets you trace the full chain: trigger event → outbound notification event → actual email content and attachments.
  • Notifications are fully customizable via templates, subject/message HTML, and drag-and-drop variables, with a Preview step before saving.
  • Good notifications add clarity; over-notifying floods inboxes — test before going live.

Detailed Notes Event-driven flow

  • Example walked through: reassigning a problem record from "problem coordinator A" to "problem manager Paul" fires a "problem assigned" event.
  • System Logs → Events module shows the trigger event (problem assigned) and dependent events (e.g., an outbound notification event).
  • Clicking an event reveals detail for tracing/troubleshooting: URI and when the event was processed.

Email logs & notification configuration

  • System Logs → Emails module lists all outbound emails; opening a record shows the exact copy sent and any attachments.
  • Opening the "Problem Assigned to Me" notification shows: the table it listens to and send condition (e.g., "assigned to changed to a non-empty value").
  • "What it will contain" tab: edit email template, subject, or message HTML; insert dynamic variables via drag-and-drop from the right sidebar.
  • Use Preview to test changes; click Update to save.

Design principles

  • Only send what's needed, when it's needed; keep messages clean, focused, relevant.
  • Notifications cover tasks, approvals, changes, and outages — they are how users stay informed.
  • "If it's not tested, it's not ready" — notifications should add clarity, never confusion.

Action Items

  • Reassign a record, then trace it in System Logs → Events and System Logs → Emails to confirm the notification chain.
  • Customize a notification: adjust the send condition, swap the email template, and inject variables via drag-and-drop.
  • Always Preview before updating a notification; schedule a test recipient pass before go-live.
  • Audit existing notification rules and prune ones that over-fire.

Key Terms/Concepts

  • Event: a logged occurrence (assignment, status change) that can trigger notifications.
  • Notification rule: configuration that maps an event to an outbound message (email/SMS/Teams).
  • Trigger event: the original event that starts the notification chain.
  • Outbound notification event: the event representing the message being sent.
  • Email template: reusable body/skeleton for notification messages.
  • Dynamic variables: drag-and-drop placeholders pulling live record data into a message.

Chapter 5 — 3. Workflow automation essentials

Core Insights

  • ServiceNow's automation tooling has four parts: Workflow Editor (legacy canvas), Flow Designer (low-code engine for new automations), Playbooks (guided agent step-by-steps), and Workflow Studio (command center that unifies them).
  • Building blocks nest like Russian dolls: Flow (trigger + finish) → Subflow (reusable routine) → Actions (atomic tasks like send email, update field, call API).
  • A practical approval flow: trigger on Service Catalog submission, an If condition on price (dot walker pulls Requested Item price), an "ask for approval" action for expensive items, and an auto-approve + update-record branch for the rest.
  • Monitor and debug via Operations → Monitoring → All Executions; governance comes from scopes, update sets, roles, versioning, and quotas.

Detailed Notes Building the approval flow

  • Access: All → Process Automation → Workflow Studio → New → Flow; name e.g. "Approval Flow for Requested Items," note "ask manager to approve items over $1,000, auto approve the rest."
  • Trigger: Applications → Service Catalog trigger (fires on catalog request submission).
  • Flow Logic → If condition named "it's expensive"; use the pill picker/dot walker to drill from trigger → Requested Item record → price; set condition price > $1,000.
  • Then branch → Action → ServiceNow Core spoke → "Ask for approval": record = Requested Item (dot walker), approval condition "anyone approves," when = opened by → manager.
  • Else branch → Action → Update Record (Requested Item): set approval = approved, closure notice = "auto approved under $1,000" (audit note), state = closed complete.
  • View flow as list or flowchart; Save, then Run Test with execution details: $600 iPad → condition false → auto-approved; $1,499 laptop → condition true → waits for manager approval. Click Activate when verified.

Monitoring & governance

  • Operations → Monitoring → All Executions: per-run status (waiting, complete, error, canceled); drill into a run to see each step's inputs, outputs, decision logic, errors/skipped steps, plus a timeline view.
  • Scope = namespace separating HR/IT automations; update sets move flows dev→test→prod; roles (admin, flow designer, delegated developer) control who creates vs runs; every save versions the flow with one-click rollback; quotas protect budgets from runaway calls.
  • Integration Hub spokes: drag in "Post Message to Teams" with the same data pills — no API key gymnastics; hub also speaks REST, JDBC, and custom spokes.
  • Best practices: start small (automate one part of a process you know), name flows table-purpose (e.g., "incident manager escalation"), and test on a sub-production instance first.

Action Items

  • Build a triggered approval flow with an If condition, dot-walker field references, ask-for-approval, and an auto-approve else branch.
  • Test both branches with run-test before activating; use a sub-production instance.
  • Activate, then monitor runs in All Executions; click into a step to review decision logic on failures.
  • Apply a table-purpose naming convention and package flows in update sets for promotion to prod.
  • Reuse a common routine as a subflow (e.g., satisfaction survey) instead of duplicating actions.

Key Terms/Concepts

  • Workflow Studio: unified command center for ServiceNow automations.
  • Flow Designer: low-code drag-and-drop automation engine (the modern tool).
  • Workflow Editor: older drag-and-drop canvas still found on long-lived instances.
  • Playbook: pre-built step-by-step guide agents follow in the workspace UI.
  • Flow / Subflow / Action: a full automation (trigger→finish) / reusable routine / atomic task.
  • Spoke: Integration Hub connector (e.g., Teams, REST, JDBC, custom).
  • Dot walker / pill picker: UI mechanism to drill into referenced record fields.
  • Update set: package that moves config (including flows) between instances.
  • Scope: namespace isolating automation between teams/departments.

Chapter 5 — 4. What is Virtual Agent

Core Insights

  • Virtual Agent is a built-in conversational chatbot that delivers 24-7 guided self-service on desktop, phone, Slack, and Teams.
  • It handles repetitive work — password resets, ticket status, request submission, FAQs, how-to walkthroughs, escalation to live agents — so human agents focus on bigger issues.
  • Even without designing conversations, admins manage where/how Virtual Agent appears and how it connects to catalog items, knowledge articles, and Flow Designer automations.
  • It uses natural language understanding (NLU) and is fine-tunable with analytics, user feedback, and suggested topics.

Detailed Notes Capabilities & admin role

  • Typical tasks: reset passwords, check incident/request status, submit new requests, answer FAQs, guide how-to processes, escalate to a live agent.
  • Admin responsibilities: troubleshoot access issues, enable Virtual Agent in a new portal, coordinate with developers to launch new topics, and understand its links to catalog, knowledge, and flow automations.

Designer & platform fit

  • Virtual Agent Designer: visual, low-code, drag-and-drop conversation building — no scripting; create new conversations, customize pre-built ones, integrate with flows and knowledge articles.
  • NLU interprets user intent (meaning), not just typed keywords; refine over time with analytics, user feedback, and suggested topics.
  • Included in most instances; even the basic version handles real interactions.
  • Available in any free developer instance with pre-built topics for IT, HR, and customer service; topic recommendations reveal what users are asking about.
  • Positioned as the "digital front desk" — increasingly central as the platform adds Gen.AI and automation.

Action Items

  • Explore Virtual Agent Designer in a free developer instance; review pre-built topics for IT, HR, and CS.
  • Use topic recommendations and analytics to find what users ask most, then build or tune conversations for those.
  • Enable Virtual Agent in a new portal and verify access end-to-end.
  • Connect a Virtual Agent topic to an existing Flow Designer automation; coordinate with a developer for complex new topics.

Key Terms/Concepts

  • Virtual Agent: Now-platform conversational chatbot for guided self-service.
  • Virtual Agent Designer: low-code drag-and-drop conversation builder.
  • NLU (natural language understanding): interprets user meaning/intent rather than exact keywords.
  • Topic: a discrete conversation (e.g., password reset) inside Virtual Agent.
  • Escalation: hand-off from the bot to a live human agent.
  • Developer instance: free personal ServiceNow instance for building/learning.

Chapter 6 — 1. Creating and managing knowledge articles

Core Insights

  • Knowledge articles turn one-off fixes into evergreen, searchable knowledge stored in knowledge bases, tagged by category and audience.
  • Articles follow a lifecycle: draft (auto-saves every 30 seconds) → review (via Flow Designer to an SME) → published → retired (after 18 months or as configured; still searchable to admins).
  • NowAssist (licensed in Enterprise/Pro instances, not free Personal Developer Instances) auto-drafts articles from incident/case title, work notes, and screenshots; the lifecycle steps stay identical to manual authoring.
  • The KB home page shows dynamic sections (featured, most useful, most viewed) driven by real user activity; user feedback (helpful, comments, ratings) guides updates.
  • Analytics — search logs, Knowledge Analytics dashboard, and AI search metrics — reveal content gaps and deflection rate.

Detailed Notes Finding and using knowledge

  • Navigate to the Knowledge application → Home page module to see all knowledge bases (IT, KCS, Knowledge, Known Error), each serving a different need.
  • Filters (category, author, tags, ratings, last modified, view count) narrow browsing and flag articles needing updates or polish.
  • Article view shows author, last-update date, and view count — transparency builds trust in currency and vetting.
  • Users contribute feedback by marking helpful, leaving comments, and rating; this helps authors and admins prioritize updates.

Editing and administration

  • Actions → Edit Article opens the editor: title, categories, full content, plus relationships at the bottom (affected products, approvals) linking the article to other ServiceNow records.
  • Updating increments the version automatically and keeps the previous version for audit; last-updated time refreshes.
  • Administration modules: Knowledge Bases (per-KB workflows, read/contribute access rules, categories, spotlight/featured articles), Search Log (queries with no results = content gap signal), Properties (articles per page, rating behavior — reversible tweaks).
  • Pro tip: schedule reports on search logs to spot no-result trends over time, then create or improve articles for recurring terms.

Best practices

  • Capture fixes the first time using ready-made templates (how-tos, Q&A, known error); keep articles snackable — under ~700 words with bullets and headings.
  • Schedule quarterly reviews; tag with product, version, and role so AI Search works well.
  • Use lifecycle rules to auto-retire content gathering digital dust.

Action Items

  • Configure the Flow Designer workflow that routes drafts to the appropriate SME for review before publishing.
  • Set per-knowledge-base access rules (who reads, who contributes) and define categories.
  • Schedule recurring reports on the search log filtered for no results; create articles for recurring unanswered queries.
  • Set up lifecycle/auto-expire rules so outdated content retires automatically.
  • Tag articles consistently with product, version, and role for AI Search.

Key Terms/Concepts

  • Knowledge base (KB): Container of articles, tagged by category and audience, with its own access rules and settings.
  • Article lifecycle: Draft → Review → Published → Retired workflow with version control and audit history.
  • NowAssist: AI assistant that drafts knowledge content from an incident or case; licensed in Enterprise/Pro instances.
  • Search log: Record of user searches revealing queries that return no results — a content-gap signal.
  • Deflection rate: Knowledge Analytics metric measuring how many tickets the knowledge base prevents.
  • Flow Designer: Low-code orchestration used to route articles to an SME for review.

Chapter 6 — 2. Updating and managing the Service Catalog

Core Insights

  • The Service Catalog is an internal online shop: catalog = storefront, categories = aisles, items = products, variables = knobs/switches the shopper adjusts (e.g., stipend amount, color choice).
  • Requests auto-route to the right team and clock their own SLA; the catalog is not IT-only — HR can list onboarding packs, facilities can list keycard access.
  • Governance split: catalog admins build drafts, catalog managers give the green light, frontline techs simply fulfill.
  • Items march through the same draft → review → published → retired states as knowledge articles, so legacy forms (e.g., old VPN form) vanish without losing history.
  • Changes promote safely between instances via update sets with clear names (e.g., stipend 2025-07); the Catalog Builder Versions tab provides an undo button.

Detailed Notes Catalog building blocks

  • Every UI element maps to a building block: the catalog (storefront), categories (aisles), items (products), and variables (user-adjustable options).
  • Users self-serve — no did-you-get-my-email follow-up threads; each request routes automatically to the fulfilling team and gets its own SLA clock.

Roles and lifecycle

  • Catalog Admin builds items in draft; Catalog Manager reviews/publishes; frontline techs only fulfill approved items.
  • Items move through draft, review, published, retired — identical states to knowledge articles — keeping request history intact when items are retired.

Moving between instances and maintenance

  • Bundle catalog changes into a well-named update set to promote safely between instances; use Catalog Builder Versions to roll back.
  • Track fulfillment metrics and usage to find items nobody orders (candidates for retirement) and items that generate questions (candidates for better variables or descriptions).

Action Items

  • Build new catalog items as drafts and have the catalog manager review and publish before go-live.
  • Retire legacy catalog items through the lifecycle rather than deleting them, preserving history and audit.
  • Group catalog changes into named update sets before promoting between instances; keep the Versions tab in mind for rollback.
  • Review variable definitions and labels so users submit correct, complete requests the first time.

Key Terms/Concepts

  • Service Catalog: Central storefront where users request internal products and services.
  • Categories and items: The aisles and products of the catalog; items carry forms and fulfillment routing.
  • Variables: User-adjustable inputs on a catalog item (e.g., amount, color, options).
  • Update set: Named bundle of changes promoted between instances (dev → test → prod).
  • Catalog Builder: Admin tool for building catalog items, with a Versions tab for rollback.
  • SLA: Service level agreement clocked per request once routed to the fulfilling team.

Chapter 6 — 3. Improving self-service with the Service Portal

Core Insights

  • Service Portal is a consumer-grade, self-service storefront (often pre-branded as Employee Center — same engine) that shields IT from where-is-my-ticket calls.
  • Users get a big search bar plus tiles (Request Something, Knowledge Base, Get Help); live widgets surface outages, approvals, and open incidents without leaving the page.
  • All basic customization is code-free via five controls: Branding Editor, Designer, Page Editor, Widget Editor (clone/tweak building blocks), and portal configuration — every change instantly updates the live storefront.
  • It is a Lego kit: pages = base plates, widgets = bricks, themes = paint, UI policies = rules hiding irrelevant pieces, data sources pipe live records (e.g., My Open Requests) into widgets without code.
  • Success = plain-language labels (reset password instead of credential reinitialization), AI Search on, analytics watched (search exits), and widget reuse with testing and role checks.

Detailed Notes Customization cockpit

  • Branding Editor swaps logos and colors in seconds and is the first stop before any CSS overrides — one logo upload updates every page with the corporate palette.
  • Designer/Page Editor drag-and-drop layouts; Widget Editor clones or tweaks widgets; themes can be previewed to test accessibility; portal configuration can hide banners. All are low-risk changes you can demo to stakeholders live.

Widgets and governance

  • High-value widgets: KB Search (surfaces facts), My Open Tickets and Reset Password (deflect email noise). Clone and tweak rather than build from scratch.
  • Data sources attach live record lists to widgets with no code.
  • With great widget power comes testing responsibility: validate on phones, label change sets for audit, and add proper role checks so HR records do not show up in finance dashboards.
  • Avoid hard-coded colors or IDs — lean on properties and variables so the next rebrand does not bite you.

Analytics and iteration

  • Portal Analytics, especially the search-exits graph, reveals queries that hit a dead end — rename widgets or reword labels, then re-check in a week.
  • Fewer clicks means fewer tickets; iterate based on what users actually click.

Action Items

  • Open Branding Editor: upload a new logo, set brand colors, and save.
  • Drag two high-value widgets (e.g., My Open Tickets, Reset Password) onto the main homepage.
  • Review Portal Analytics search exits weekly; reword or rename anything with dead-end queries and re-measure.
  • Reuse and clone proven widgets, label each change set for audit, and validate on phones before declaring victory.

Key Terms/Concepts

  • Service Portal / Employee Center: Branded self-service front end to ServiceNow; Employee Center is a pre-branded variant on the same engine.
  • Widget: Reusable front-end building block (e.g., KB search, My Open Tickets); cloneable and customizable in Widget Editor.
  • Page: Layout container (base plate) assembled in Designer/Page Editor.
  • Theme: Visual paint job for the portal, changeable and previewable for accessibility.
  • UI policy: Rule that shows or hides portal elements based on context.
  • Data source: Attaches live records (e.g., my open requests) to widgets without code.
  • Search exits: Analytics graph of user queries that produced no result — a dead-end signal.

Chapter 7 — 1. Importing data with Import Sets

Core Insights

  • Import Sets are ServiceNow's staging area for external data (Excel, XML, JDBC feeds, FTP drops), accessed under System Import Sets in the All menu.
  • The entire workflow is a three-stage model: load → map → run. Load rows into a scratch table, map them to a target table with a transform map, then run the transform to push clean data into production tables.
  • Coalesce on a unique key (e.g., user ID) is the duplication-protection seatbelt: it tells ServiceNow to update an existing record instead of creating a duplicate.
  • Import Sets aren't just one-offs — the Scheduled Import Workspace plus IntegrationHub spokes enable nightly loads or flow-triggered imports (set it and forget it).

Detailed Notes Load

  • Click Load Data → name the load (e.g., "New Users") → pick the CSV/spreadsheet → Submit.
  • Always open Loaded Data afterward to eyeball what actually landed in the staging table.

Map

  • Create a Transform Map: set source = import set (staging table) and target = destination, e.g., sys_user for users.
  • Click Automap Matching Fields to auto-match; fix gaps in Mapping Assist by dragging source fields to target fields (e.g., ID → user ID, work → business phone).
  • Set coalesce = true on the unique key field so re-runs update instead of duplicating.

Run

  • Run Transform; multiple maps can be stacked and execute top-to-bottom for complex feeds.
  • Verify results by searching the target table (e.g., Users) and checking the imported record's fields.

Action Items

  • Practice the load-map-run workflow with the provided sample file in a dev instance.
  • Always set coalesce = true on at least one unique key per transform map.
  • Open Loaded Data after every load to sanity-check staging rows before mapping.
  • For recurring data (nightly HR loads), evaluate the Scheduled Import Workspace or an IntegrationHub flow trigger.

Key Terms/Concepts

  • Import Set: a staging table holding raw external data before transformation.
  • Transform Map: the mapping definition between a source import set and a target table.
  • Coalesce: flag that matches records on a key field; true = update existing, false = always insert.
  • Mapping Assist: drag-and-drop UI for manually pairing source fields to target fields.
  • Automap Matching Fields: automatic field-matching feature for transform maps.

Chapter 7 — 2. Data management best practices

Core Insights

  • Dirty data (NYC vs. New York vs. New York City) breaks dashboards and SLAs; cleanup after the fact can cost 10x what prevention costs — guardrails are cheaper than cleanup.
  • Normalization standardizes values (store the same thing the same way); validation blocks bad data from entering at all. Both are needed.
  • Choice lists, reference fields, and lookup rules force sanctioned values for users and incoming CSVs; lookup rules turn "MSFT"/"Microsoft Corp" into "Microsoft".
  • UI policies only govern the UI; data policies apply the same mandatory rules to integrations so REST APIs can't sneak in blanks or typos.
  • Resist adding fields: each extra column multiplies maintenance/integration effort — reuse or extend existing fields, and use dictionary overrides instead of cloning.

Detailed Notes

  • Required fields are "seatbelts" — pair them with sensible defaults (e.g., priority = 4/low) to capture essential info without slowing users down.
  • Even perfect gates leak: run monthly reports for empty/duplicate values, enable duplicate detection on users and companies, schedule archival jobs to retire tickets older than ~3 years.
  • Normalization Data Services plugin (ITAM/ITOM Pro) can automate normalization for the CMDB, beyond intro scope.

Action Items

  • Tag your top 5 mission-critical tables for a data-quality once-over.
  • Add a data policy with mandatory fields to every new custom table you create — day 1, so blanks never sneak in.
  • Schedule a monthly data-quality snapshot report that lands in your inbox automatically.
  • Bookmark the normalization plugins/guided setups so you're ready if the business adopts ITOM Pro.

Key Terms/Concepts

  • Normalization: storing the same thing the same way every time (choice lists, reference fields, lookup rules).
  • Validation: blocking bad/typo data at entry (required fields, UI/data policies).
  • UI Policy: rules applied to the user interface only.
  • Data Policy: same mandatory-field rules enforced for all data sources including integrations.
  • Dictionary Override: customizing an existing field's dictionary entry instead of cloning the field.

Chapter 7 — 3. CMDB best practices

Core Insights

  • The CMDB (Configuration Management Database) stores CIs and their relationships so teams trace outages in minutes instead of hunting tribal knowledge — but its power is proportional to its accuracy: garbage in = outages out.
  • CI classes form a hierarchy (cmdb_ci → cmdb_ci_computer → cmdb_ci_laptop): child tables inherit fields from parents, so you add laptop-only attributes (e.g., battery health) at the right level.
  • CIs come alive through relationships — upstream items affect you, downstream items depend on you; a CI with no links is an orphan (fine for asset counts, useless for impact analysis).
  • ServiceNow scores the CMDB on three health bars: Completeness (missing must-have fields), Correctness (impossible data), and Compliance (naming/lifecycle rules); red bars mean incidents and changes will suffer.

Detailed Notes

  • CMDB Workspace gives an executive snapshot: health scores, recent edits, data-quality tasks, CMDB 360 shortcut — everything is drill-down ready (click a component to view/modify/fix data).
  • Dependency views visualize services mapped to databases/servers/computers; hovering links shows how CIs connect ("depends on", "exchanged data with", "cooled by").
  • Red X icons mark incidents in related CIs; orange table icons mark open changes — context that helps pinpoint root cause.
  • Add relationships via right-click → View Map → Add Relationship (Visio-style line), or View Form → related items "+" to manually configure a "connects to" relationship.
  • CMDB Workspace → Important Actions surfaces dedup tasks, duplicates, and stale CIs; dedup manually via the three-dot menu and review stale CIs to keep attributes/relationships current — do these when incident volume is low.

Action Items

  • Check the CMDB health dashboard weekly; treat any red bar as a defect to fix, not a stat to ignore.
  • Never let a new CI enter untagged — attach at least one relationship so incident responders see the full picture.
  • Work dedup and stale-CI tasks regularly (schedule them during low incident volume).
  • Fix small data flaws immediately instead of letting them compound into large-scale cleanup.

Key Terms/Concepts

  • CI (Configuration Item): a single unique record, e.g., Laptop123 or dbprod01.
  • CI Class: the type of a CI, organized in an inheritance hierarchy.
  • Relationship: a connection between CIs (upstream affects you, downstream depends on you).
  • Dependency View: live graph showing CI connections to assess outage blast radius.
  • CMDB Health: completeness + correctness + compliance scoring of the CMDB.

Chapter 7 — 4. CSDM essentials

Core Insights

  • The Common Service Data Model (CSDM) gives every ServiceNow app the same dictionary so finance, security, and IT talk about the same thing — fixing mismatched labels that cause bad reports, broken automations, and audit headaches.
  • CSDM is a four-layer storyboard: Design (digital product idea) → Manage (technical services / business applications you own, e.g., Workday) → Sell & Consume (app as a service offering customers request) → Operate (application services tied to real servers, databases, network gear).
  • Remember just two tables: a business application answers "who owns this? how much does it cost?"; an application service answers "is it up? which server is down?" Link them once and dashboards, incidents, and SLAs inherit correct context.
  • You don't need Discovery or an army of architects to start — begin with your 10 most critical apps.

Detailed Notes

  • CI class manager → filter for "application service" → right-click a CI → Show Relationships reveals all business applications one hop away — CSDM in action.
  • Common missteps: tagging CIs without a real owner (orphans nobody fixes) and mapping every printer on day one (analysis paralysis — start with business-critical apps).
  • Deeper resources: CSDM white paper on the Now Community; in-instance Validate CSDM wizard in CI class manager acts as a spell-checker for relationships; Slack channels and the ServiceNow community for help.

Action Items

  • Pick your 10 most critical apps and create/tag them as business applications.
  • Map each business application to the single application service you monitor.
  • Assign an owner and a support group to each.
  • Run the Validate CSDM wizard to check relationship hygiene.

Key Terms/Concepts

  • CSDM (Common Service Data Model): shared data model giving every ServiceNow app the same vocabulary.
  • Business Application: CSDM record answering ownership and cost.
  • Application Service: CSDM record answering availability (is it up, which server is down).
  • Validate CSDM Wizard: relationship spell-checker in CI class manager.

Chapter 7 — 5. Scripting basics: What admins should know

Core Insights

  • Scripting is the admin's Swiss Army knife: server-side scripts work invisibly (backstage crew) to manage data; client-side scripts make forms responsive in real time (front-stage performers). Heavy lifting = server-side; UX tweaks = client-side.
  • A Business Rule triggers after a record saves — perfect for updating parent tickets; a UI Policy reacts instantly to user choices (e.g., showing approval notes when priority = high).
  • Before scripting, ask "could Flow Designer do this?" — flows are safer/easier for ~80% of admin tasks (routing, alerts); scripting excels at the other 20% (SLA breach calculations, external API calls).
  • One bad script can open security holes: validate user roles explicitly, never assume admin access, and escape user-entered data to block attacks.

Detailed Notes

  • Power tools and safety checks: always test scripts with debug statements before going live; GlideRecord is the server-side query friend, GlideAJAX safely bridges to clients.
  • Diagnosing scripts: check basics first (is the script active? does the user have the right roles?); server-side → search system log for script error messages; client-side → browser DevTools (F12) console log.
  • Performance: never loop through records without limits — that's how you summon the "performance monster" (timeouts).
  • Real-world wins: auto-assignment rule routing tickets by location (~20 hours/month saved), nightly duplicate-user cleanup keeping sys_user pristine.
  • Always test changes in a dev instance before production.

Action Items

  • Automate one tedious task: e.g., default a field value or hide a section for certain roles with a UI policy.
  • Add debug statements and test in dev before any script goes live.
  • Add explicit role validation and output escaping to any script that handles user data.
  • Evaluate Flow Designer first for any automation; reserve scripts for logic flows can't express.

Key Terms/Concepts

  • Server-side script: runs on the server to manage data (business rules, GlideRecord).
  • Client-side script: runs in the browser to react to form changes (client scripts, UI policies).
  • Business Rule: server-side script that runs on record save/update.
  • UI Policy: client-side rules that show/hide fields or set values based on user choices.
  • GlideRecord / GlideAJAX: server-side query API / client-server bridging API.
  • Flow Designer: no-code/low-code automation designer preferred for most admin automations.

Chapter 7 — 6. Moving changes with Update Sets

Core Insights

  • An update set is a shipping container for platform tweaks: label it, make it current, and every configuration save writes an XML snapshot into it; seal it (complete), forklift it to test, preview, then commit.
  • It acts like a GoPro on your config workbench: it records structural changes (schema tweaks, UI policies, catalog variable sets) but deliberately ignores day-to-day business data (tasks, user records, orders) — don't expect users/incidents to move with it.
  • The global set is a junk drawer — always quarantine work in a named set (name it with purpose + date) for easy testing and rollback; the red circle around the globe icon confirms capture is active.
  • The pipeline is: create & make current → watch the counter → complete → retrieve → preview (fix reds until green) → commit.

Detailed Notes

  • Open the globe icon to see the current update set; create a named set, submit + make current. One-time setup for cross-instance transfer: System Update Sets → Update Sources → New, with a friendly name, type test, active flag, and the dev URL ending in /api/now/update_set (the suffix is mandatory — miss it and the handshake fails); test connection (green check; red X is usually an IP allow list or URL typo).
  • Retrieve Completed Update Sets downloads the package (nothing touches your data); the set lands in Retrieved Update Sets with a loaded badge.
  • Preview flags conflicts: red = must fix (usually duplicate field or older-timestamp issue), yellow = warning; re-preview until a "sea of green," then commit in lower environments first — in production, commit is forever (no Ctrl+Z).
  • Release-gap rule: moving old → new releases is safe; new → old can break things — upgrade or clone forward when in doubt.
  • Sealing (complete = shrink wrap) stops new items; reverting to in-progress breaks the audit trail, so double-check before sealing.

Action Items

  • Give every new update set a unique, human-friendly name with purpose + date, and mark it current before the first tweak.
  • Watch the update-set record counter as a live sanity check — if it's not climbing, nothing is being captured.
  • Practice walking a harmless change (e.g., a catalog item) dev → test → prod to build muscle memory.
  • Always verify in a lower environment before committing in production; never move changes from a newer to an older release family.

Key Terms/Concepts

  • Update Set: container capturing configuration (structural) changes as XML for transport between instances.
  • Global Update Set: default catch-all set; treat as a junk drawer, avoid making changes in it.
  • Update Source: configured connection (dev URL + credentials) that lets test/prod retrieve completed update sets.
  • Preview: conflict check before commit — reds must be fixed, yellows are warnings.
  • Commit: final application of the update set; irreversible in production.

Chapter 8 — 1. Generating reports and metrics

Core Insights

  • ServiceNow's data visualization area centralizes all reporting tools on the All Reports landing page, filterable by ownership (owned by me, shared with me).
  • The visual report designer works like Excel: live charts that update in real time as you configure them, and clickable chart elements drill down to matching records.
  • Reports pull from a chosen data source (table), can be restricted with predefined conditions, and use group-by fields to shape the chart.
  • Stacked bar charts enable Pareto-style analysis by adding a second grouping dimension.
  • Reports can be automated via Scheduled Reports to email recipients on a recurrence, e.g., weekly before a status meeting.

Detailed Notes Visual designer basics

  • Edit the visualization name at the top; the right panel holds visualization type, data source, chart type, and Excel-like formatting options.
  • Charts are live: clicking any box drills down to the matching records — useful for root cause hunts and managers wanting behind-the-scenes detail.

Building a new report (incidents by assignment group)

  • Click New → add a data source (Incident table); predefined conditions can restrict the data feeding the visualization.
  • Set visualization type to Vertical Bar; there are many chart options to choose from.
  • Group by Assignment Group; the chart updates in real time on Apply, making design iterative and fast.
  • To Pareto the data, Add a second group type (e.g., Assigned To) to create a stacked bar.

Scheduling delivery

  • Save with a title, then open the Scheduled Reports module (nothing configured by default).
  • Create a new schedule: name it, select recipient users, set a subject line and introductory message.
  • Set recurrence (e.g., weekly) and a delivery time that looks human — e.g., 6:53 a.m. before a 7 a.m. meeting.
  • Submit to deliver a fresh report automatically every week.

Action Items

  • Open All Reports and filter by "owned by me" / "shared with me" to audit existing reporting assets.
  • Build a test report: add the Incident table as data source, set Vertical Bar grouped by Assignment Group, then Add a second group (Assigned To) for a stacked/Pareto view.
  • Save the report, then create a Scheduled Report with recipient users, subject, message, weekly recurrence, and a deliberately non-round delivery time.

Key Terms/Concepts

  • All Reports landing page: central hub listing every report, filterable by ownership and sharing status.
  • Visual designer: the report builder where name, visualization type, data source, chart type, and grouping are configured live.
  • Data source: the table a visualization pulls information from, optionally filtered by predefined conditions.
  • Group by: chart dimension that aggregates records (e.g., by Assignment Group); adding a second group creates a stacked bar for Pareto analysis.
  • Scheduled Reports module: automates report delivery to selected users on a recurring schedule via email.

Chapter 8 — 2. Building dashboards for real-time insight

Core Insights

  • A dashboard is mission control: one auto-refreshing page aggregating live metrics (incidents, SLAs, requests) instead of opening ten separate reports.
  • Layout is drag-and-drop; visibility per viewer is controlled by roles and share settings, so managers see everything while specialists see only what they need.
  • Dashboards are assembled entirely from existing building blocks: reports, performance analytics scorecards, external URLs, and text notes.
  • A global time filter on every dashboard lets viewers shift the whole page's time range without editing individual widgets.
  • Dashboards can be bookmarked, shared by role/group/user, scheduled as PDF exports, and embedded into workspaces or Employee Center.

Detailed Notes The Dashboards module / library

  • The library's left rail filters to dashboards you own, shared with you, or system-wide; tiles show previews with bookmark and info icons.
  • Create New Dashboard (purple button): give a clear name (e.g., Service Desk Health) and short description; owner defaults to you and can be transferred later.
  • Set time zone for global teams; choose private while experimenting or share immediately with specific roles/groups.

Building the canvas

  • Add Content, usually an existing report, which renders exactly as in Report Designer; Performance Analytics scorecards, external URLs, and text notes are equally easy.
  • Resize widgets from the corner; drag the header to reposition.

Distribution

  • Top time filter: switch Today → Last 30 Days page-wide, no widget edits needed.
  • Share tab: list roles, groups, or individual users for access.
  • Bookmark for one-click access in favorites; schedule a PDF export for leadership (e.g., Mondays at 8 a.m.) to eliminate copy-paste work.
  • The same dashboards embed into workspaces or Employee Center for a seamless user experience.

Action Items

  • Open the Dashboards library and filter the left rail to audit owned/shared/system dashboards.
  • Create a dashboard (e.g., Service Desk Health) with name, description, time zone, and privacy scope; default owner to yourself.
  • Add Content from existing reports, resize/reposition widgets, then use the global time filter to validate across time ranges.
  • Configure the Share tab with roles/groups/users, bookmark it, and schedule a recurring PDF export for leadership.
  • Embed the finished dashboard in a workspace or Employee Center for end-user visibility.

Key Terms/Concepts

  • Dashboard: a single drag-and-drop page aggregating live, auto-refreshing metrics from multiple sources.
  • Dashboard library: the landing view listing dashboards, filterable by owned/shared/system-wide.
  • Add Content: dialog for adding widgets — existing reports, Performance Analytics scorecards, external URLs, or text notes.
  • Time filter: page-level control (Today, Last 30 Days, etc.) that refreshes every widget's range at once.
  • Share tab / roles: access control for dashboards by role, group, or individual user.
  • PDF export schedule: recurring automated email delivery of a dashboard snapshot for stakeholders.

Chapter 9 — 1. Next steps with ServiceNow

Core Insights

  • The course lays a foundation (incidents, catalogs, ACLs, automation) that is a launch pad, not the finish line — new platform releases add GenAI features (Now Assist suggestions, AI Search 2.0 relevance boost, copilots that build flows from plain English) that this base lets you adopt quickly.
  • Deepen value by widening scope: Flow Designer + Integration Hub (automation architect), Performance Analytics (executive insight from log noise), Virtual Agent and AI Search (cut ticket volumes), and CMDB/ITOM (infrastructure management with precision).
  • The CSA (Certified System Administrator) exam is the industry credential; the course followed its blueprint, but real muscle memory comes from tinkering in a personal development instance.
  • Community is the multiplier: forums, user groups, and release notes keep you current; applying skills to real work compounds value and turns ServiceNow into a career trajectory.

Detailed Notes Your foundation

  • Incidents, service catalogs, ACLs, and a dash of automation are now under your belt; the course content tracked the CSA exam blueprint throughout.
  • The platform adds new GenAI muscle each release — Now Assist suggestions, AI Search 2.0 relevance boost, copilots building flows from plain English — so a solid base means adopting new tools rather than playing catch-up.

Expansion paths

  • Flow Designer + Integration Hub → automation architect role.
  • Performance Analytics → turns log noise into executive insight.
  • Virtual Agent + AI Search → reduces ticket volumes.
  • CMDB + ITOM → surgeon-level infrastructure management.
  • Strategy: pick one lane, run a pilot, and watch value spike.

Credentialing and growth

  • CSA exam is the industry handshake; practice by breaking and fixing things in your own dev instance, then walk into the test center with confidence.
  • Plug into forums and ServiceNow user groups, skim every release note as it drops, then fix something real at the office — each win compounds.

Action Items

  • Get a personal ServiceNow developer instance and deliberately break/fix things to build exam muscle memory.
  • Register for and study toward the ServiceNow Certified System Administrator (CSA) exam.
  • Choose one advanced track to pilot (Flow Designer/Integration Hub, Performance Analytics, Virtual Agent/AI Search, or CMDB/ITOM).
  • Join ServiceNow forums and a local user group; subscribe to release notes to stay current.
  • Connect with the instructor on LinkedIn and apply a real fix at work to compound the learning.

Key Terms/Concepts

  • Now Assist: GenAI feature set embedded in ServiceNow offering suggestions/assistance across workflows.
  • AI Search 2.0: AI-enhanced search with relevance boosting for better results.
  • Flow Designer / Integration Hub: Low-code automation design and system integration tools.
  • Performance Analytics: Dashboards/metrics that translate operational data into business insight.
  • Virtual Agent: Conversational chatbot that deflects tickets and automates requests.
  • CMDB / ITOM: Configuration Management Database and IT Operations Management for infrastructure visibility and control.
  • CSA (Certified System Administrator): Official ServiceNow certification validating core administration skills.
  • Development Instance: Personal sandbox ServiceNow instance for safe learning and experimentation.
Reference in New Issue View Git Blame Copy Permalink