ITSM NOTES

SLA Type	Description	Example	Used in ServiceNow
Customer-based SLA	Agreement between the service provider and a specific customer covering all services they use.	ABC Corp’s incidents resolved within 4 hours.	Applied using conditions or customer fields on SLA definitions to target specific customers.
Service-based SLA	Defines performance for a particular service for all users/customers.	Email service issues resolved in 6 hours.	Applied using the Service Offering or Service field in SLA definitions.
Multi-level SLA	Combination of corporate, customer, and service-level SLAs within one structure.	Corporate: common rules; Customer: 24x7 support; Service: 4-hour resolution.	Configured using multiple SLA definitions targeting different layers (global, customer, service).
Operational Level Agreement (OLA)	Internal agreement between support or resolver groups to meet SLA goals.	Network team resolves connectivity issues in 2 hours.	Created as internal SLA definitions (type = OLA) to track internal team performance.
Underpinning Contract (UC)	Agreement with external vendors or suppliers supporting the main SLA.	ISP restores connectivity within 1 hour.	Configured as UC-type SLA definitions, linked to vendor or supplier records.

=======================================================================================

Notification Types in ServiceNow 👇

Notification Type	Description	Example	Used In ServiceNow
Email Notification	Sends automated emails based on events, conditions, or record updates.	Notify assignee when an incident is assigned.	Configured under System Notification → Email → Notifications.
SMS Notification	Sends text messages to users’ mobile numbers for important alerts.	Send SMS when a high-priority incident is created.	Uses SMS gateway or Notify plugin for SMS delivery.
Push Notification	Sends alerts to mobile devices via the ServiceNow mobile app.	Push alert when a change request is approved.	Configured through Mobile Push Notifications.
Workplace/Chat Notification	Sends messages via collaboration tools like Microsoft Teams or Slack.	Message sent to Teams channel when a major incident is declared.	Uses Virtual Agent or IntegrationHub with chat platforms.
Event-based Notification	Triggered by system events (like record insert/update/delete).	Notify user when a task state changes to “Closed”.	Created using event registry and triggered via gs.eventQueue() in scripts.
Flow Notification	Sent as part of a Flow Designer automation.	Flow sends an email when a risk is approved.	Configured in Flow Designer → Notification actions.

==========================================================================================

Email Types in ServiceNow 👇

Email Type	Description	Example	Used In ServiceNow
Outbound Email	Emails sent from ServiceNow to users or external recipients.	Notify assignee when an incident is assigned or resolved.	Configured under System Notification → Email → Notifications.
Inbound Email	Emails received by ServiceNow to trigger actions or create/update records.	User sends an email to “incident@company.com” to create an incident.	Managed under System Mailboxes → Inbound → Inbound Actions.
Email Notification	Predefined templates triggered by specific record changes or conditions.	Send email when a change request is approved.	Created under System Notification → Email → Notifications.
Email Digest / Scheduled Email	Summarized or periodic emails sent at scheduled times.	Daily incident summary report emailed to managers.	Configured using Scheduled Jobs or Reports → Email Schedules.
Email Template	Reusable format for email body and subject with variables.	Template used for “Incident Assigned” notification.	Managed under System Notification → Email → Templates.
Email Script	Scripted logic to customize email content dynamically.	Add dynamic greeting or record-specific info in email body.	Created under System Notification → Email → Scripts.

=========================================================================================

📘 Types of Tables in ServiceNow

Table Type	Description	Example Table	Parent/Extended From	Default Fields (Common)	Used In ServiceNow
Base Table	A core system table that is not extended from any other table. It provides fundamental fields used across the platform.	Task, CMDB_CI, sys_user	None	sys_id, number, short_description, created_by, created_on, updated_by, updated_on	Forms the foundation for other extended tables (e.g., Incident, Problem).
Extended Table	A table that inherits fields and properties from a parent (base) table. Used for specialization.	incident, problem, change_request	task	Inherits all task fields + specific ones like impact, urgency, category	Used to create specific records like incidents or changes with shared task behavior.
Parent Table	The table from which another table extends. Provides reusable fields to child tables.	task (parent for incident, problem, change)	—	number, short_description, priority, assigned_to, state	Helps maintain consistent data and workflows across related tables.
Core Table	Default ServiceNow-provided tables that come with the platform.	sys_user, cmdb_ci, task	Varies	Depends on table (e.g., sys_user: name, email, active)	Used as the backbone of the platform for users, tasks, configuration items, etc.
Custom Table	User-created tables for custom applications or processes.	u_employee_survey, u_vendor_risk	Optional (can extend another table)	sys_id, created_on, updated_on, u_custom_fields	Used for custom app development and non-standard processes.
System Table	Internal tables that store platform configurations, logs, and definitions.	sys_email, sys_audit, sys_properties	None	Varies (system-managed)	Used for backend operations like logging, auditing, and settings.
Dictionary Table	Stores metadata about all tables, fields, and their attributes.	sys_db_object, sys_dictionary	None	name, label, type, column_name	Used to define or modify table/field structures.
Join/Mapping Table	Used to map many-to-many relationships between tables.	task_ci, cmdb_rel_ci, user_has_role	None	sys_id, table1, table2	Used for relationships like task–CI or user–role mapping.

===========================================================================================

📝 Field Behavior Rules in ServiceNow

Rule Type	Description	Example	Applied On	Default/Typical Fields	Used In ServiceNow
Mandatory Field (UI Policy)	Makes a field required on the form dynamically based on conditions.	Make assignment_group mandatory if priority = 1.	Form field	field_name, mandatory, condition	Ensures users cannot submit a form without filling mandatory fields.
Read-Only Field (UI Policy)	Makes a field non-editable dynamically.	Make reported_by read-only for all users except admins.	Form field	field_name, read_only, condition	Prevents unauthorized users from modifying fields.
Hidden Field (UI Policy)	Hides a field from the form dynamically.	Hide u_manager_comments unless state = review.	Form field	field_name, visible, condition	Controls form visibility based on conditions.
Mandatory Field (Dictionary Entry)	Marks a field as mandatory at the database level.	short_description field in incident table is mandatory.	Table field	mandatory, default_value	Always enforces mandatory at record creation, independent of UI.
Read-Only Field (Dictionary Entry)	Field cannot be modified in the UI or by scripts.	sys_id or created_on fields are read-only.	Table field	read_only, default_value	Protects system-managed fields from accidental changes.
Client Script	Uses JavaScript to make fields mandatory, read-only, or hidden dynamically based on complex conditions.	Make u_risk_score mandatory if risk_category = High.	Form field	field_name, script, type (onLoad/onChange)	Provides dynamic behavior not achievable with UI Policies alone.
Business Rule	Server-side script that can enforce rules like mandatory or read-only before database operations.	Prevent saving an incident if impact is empty.	Table/Record	condition, script, when (before/after)	Ensures data integrity on server side, even if UI is bypassed.

---

Quick Notes:

• UI Policies → Client-side, dynamic behavior for forms.

• Dictionary Mandatory/Read-Only → Database-level, enforced always.

• Client Scripts → Dynamic, conditional, can do complex logic.

• Business Rules → Server-side, protects data integrity beyond UI.

======================================================================================