docs(course-notes): 新增 ServiceNow Basic Administration 课程笔记（26 视频，目录由 xingzhi 移入 knowledgebase/course-notes）
This commit is contained in:
986
knowledgebase/course-notes/ServiceNow-Basic-Administration-Notes.md
Executable file
986
knowledgebase/course-notes/ServiceNow-Basic-Administration-Notes.md
Executable file
@@ -0,0 +1,986 @@
|
||||
# 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
Block a user